Date: Wed, 12 Jun 2002 00:23:56 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: hackers@FreeBSD.org, Julian Elischer <julian@elischer.org> Subject: Re: Is there any co-operation between KSE and similar effort in NetBSD? Message-ID: <3D06F70C.A93A1DF3@mindspring.com> References: <3D06ED9B.43EE1EF8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxim Sobolev wrote: > I wonder if there is any co-operation between our KSE and similar > effort in NetBSD (see > http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html). To > me it sounds logical to unite efforts if not for the kernel code, but > at least for the kernel interfaces and userland library. FreeBSD developers are aware of the implementation of scheduler activations within NetBSD. For the most part, the NetBSD implementation is a fairly faithful implementation of the original Scheduler Activations paper. The FreeBSD effort attempts to achieve better performance by going a slightly different route, with the similar goal of creating a call conversion threading mechanism (a blocking call is converted into a non-blocking call plus a thread context switch that does not result in a heavy weight process context switch, as in the SVR4 and Linux threading implementations). If you read the FreeBSD papers on KSE's, the intention is to ensure SMP scalability via threading (not an issue that was addressed by the original SA paper), and to minimize context switch overhead, far more than can be achieved by naieve kernel threading (as in SVR4 and Linux), without putting the thread group affinity into the kernel scheduler, with dangerous and unpredictable stavation deadlocks having a high probability of occurring. When I originally coined the term KSE (Kernel Schedulable Entity), it was intentionally different terminology from the exiting literature, so as to not bias implementation. My original view of implementation was that an async call gate, not scheduler activations, would be used, in order to make all system calls asynchronus completion (a blocking context would be late-bound only as necessary, so all calls operating from in-core data, e.g. "getpid()", "getppid()", "gettimeofday()", etc., would complete without the creation of a context). The eventual settlement on the modified SA approach was as a result of a design decision by Jason Evans, after significant architectural discussion held both on the mailing lists, and at the Whistle Communications "all hands" room during BAFUG meetings on the topic. As you can see: the use of the new terminology was successful in avoiding bias, even if it didn't arrive at the more radical answer I wanted (ironic that the 64 bit change is going to add a new call gate for a new libc, and that that call gate will also not be asynchronous, when the original argument against an async call gate was the call gate change required ;^)). In any case, the FreeBSD people have examined and learned what they felt they could from the NetBSD implementation, but the final FreeBSD implementation is unlikely to share much, if any, code. You would probably be well advised to look at the FreeBSD KSE project pages, and examine the archived architectural and design documents there, for more information, if you are truly curious about the FreeBSD implementation. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D06F70C.A93A1DF3>