Re: How much of microkernel?

["Thomas E. Spanjaard" <tgen@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature