DragonFly kernel List (threaded) for 2003-07
Re: Annoucning DragonFly BSD!
Hi Ken, excellent questions and I hope you don't mind me CCing to
the kernel list for archival purposes. I'll answer your other questions
under separate cover.
:I was reading your description of "userapi" from your site, and I noticed
:that all syscalls go through a userland process, then are passed as
:messages to the kernel if need be. I'm curious about this, mainly because
:this sounds a heck of a lot like a microkernel. Which leads me to another
:question. Did you make sure that context switching is fast?
The message passing into the kernel is not intended to be any more or
less efficient then the current syscall mechanism. The intention is
to cleanup the USER<->KERNEL API, to create an encapsulation that can
be asynchronized in the kernel (potentially run multiple syscalls in
the kernel in parallel), and to support fully asynchronous system
calls (support multi-threaded user programs without having to create extra
contexts in the kernel).
Context switching speed depends primarily on two things: (1) Base overhead
for entering and leaving the kernel and (2) Additional overheads related
to concurrency issues within the kernel (e.g. the MP lock, mutexes,
whatever). DragonFly takes a good whack at #2 and is only slightly slower
then -stable (and far faster then -current), at least in regards to MP
locked operations. DragonFly depends on implied locks on curthread and
curproc, certain features of the light weight kernel threading subsystem,
and delayed priority adjustments for user->kernel and kernel->user
transitions to reduce overhead.