How much of microkernel?

[Thomas E. Spanjaard]

Matthew Dillon wrote:
:I think L4 and Mungi have proven that doesn't have to be the case these 
:days.
    Well, I am not an expert on L4 or Mungi, but I can count cpu cycles, 
    and having to do a context switch eats a *lot* of computer cycles,
    and having to do a context switch which involves a change in the
    protection map eats even *more* computer cycles.  So many, in fact,
    that the overhead often exceeds the overhead of the operation one is
    trying to execute.
A relevant benchmark here is the lat_ctx benchmark of lmbench, of which 
a comparison between Linux and L4 is given on [1]. Pretty impressive 
results I'd say, even when the rate of context switches is higher.

    One then winds up in a situation where one must hack the code to pieces
    to make it efficient... to reduce the number of context switches that
    occur.  For example, a number of people have advocated that the TCP stack
    be moved to userland.  To my mind this is *NOT* micro-kernelish, as one
    then has no protection between the userland application and the networking
    stack.  Shifting the work around without introducing new protection
    realms is NOT a microkernel architecture.  It offers no additional
    reliability or debuggability to the system, and makes the code such a
    huge mess that it becomes unmaintainable.
I don't agree with that either, but I do like a network stack as a 
server in userland, but ofcourse in its own protection domain; Given 
efficient sharing of memory between protection domains so you don't have 
to copy data and a fast context switch, I think the little loss in 
performance is outweighed by the advantages of live subsystem 
upgrade/replacement, more defined protection between subsystems and the 
other usual advantages of microkernel designs.

Cheers,
--
        Thomas E. Spanjaard
        tgen at xxxxxxxxxxxxx
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20060822/3e7ddb06/attachment-0020.obj>