From owner-freebsd-hackers Mon Aug 21 18: 1:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id D860037B507 for ; Mon, 21 Aug 2000 18:01:27 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA96232; Mon, 21 Aug 2000 21:01:13 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 21 Aug 2000 21:01:13 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jonas Bulow Cc: hackers@freebsd.org Subject: Re: freebsd and non-preemtive threads In-Reply-To: <3997C2C5.83AFE056@servicefactory.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Both Coda and Arla make use of an LWP implementation originating at CMU. I believe that the implementation can make use of timers to add preemption, but know that in Coda preemption is not supported: LWPs are used to represent in-process (potentially blocking) RPCs on both the client and server, and are quite light weight, meaning low context-switch overhead with minimal kernel involvement. As a result, AFS and Coda servers tend to run with hundreds, if not thousands of threads: a feat not possible in many 1:1 userland thread/kernel mappings (Linux kernel threads, for example), and often not all that scalable in m:n models. However, as with other library-based thread mechanisms, you have to be careful to direct potentially blocking calls through the thread-aware versions of the calls so as not to block all other threads. As the LWP code used in AFS/Coda/Arla uses select() for blocking/timeout management, there are some scalability issues with lots of blocked threads--these might be improved through use of poll() or kqueue(). For reference, my recollection is that peemption-aware userland thread libraries tend to make alot of timer syscalls, losing some of the advantage of being a userland thread library (low context switch cost, few transistions between user/kerneland). The AFS LWP code included a fasttime() mechanism that took advantage of the ability to mmap kernel memory under SunOS, allowing direct access to the timer variable in kernel, without a context switch. I do not believe that native ports to Linux/FreeBSD/et al have retained this capability, especially given its requirements for privilege. However, it would be easy to imagine a kernel module exporting a /dev/time, which had the singular ability of allowing the mmaping of a page containing only the kernel's timer variables, permitting syscall-free precise time access from userland using atomic memory access calls. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message