How much of microkernel?

[Bill Huey (hui)]

On Tue, Aug 22, 2006 at 09:35:15PM +0200, Joerg Sonnenberger wrote:
> On Tue, Aug 22, 2006 at 07:22:57PM +0000, Thomas E. Spanjaard wrote:
> > Thomas E. Spanjaard wrote:
> > >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.
> > 
> > Doh.
> > 
> > [1] http://www.ertos.nicta.com.au/research/l4/performance.pml
> 
> This has been commented on as bogus before. In fact, most of the Linux
> on top of L4 benchmarks are somewhat bogus, e.g. the original port was
> "relatively" fast due to the short comings of the 2.4 kernel in various
> areas, which got compensated by the L4 port.


Which begs the comment from me that the Linux context switch logic is
just about the best it can be for a system driving by a timer that calls
routines for the interactive scheduler and handle memory maps as well.
The modern Linux kernel, 2.6, should be about as fast as a microkernel
such as that without hitting userspace. Most microkernel system don't
have a userspace so it's not really a valid consideration.

It's much like the dual kernel verses single kernel RT discussion that
I flame fanned a long time ago in lkml. The faction that I disagreed
with claimed that having a dual kernel system is not only more
deterministic but faster overall because of their mimimally sized kernel.

In actuality, it's the same stuff. The manipulation of the interrupt
controller, context switch in kernel space all of the mechanisms in
a dual or host kernel system were pretty much the exact replics
logically but smaller versions of the same thing in the 2.6 Linux kernel.
At that point, it's probably easier to modify the stock kernel to be
optimized better for those kind of operations.

Yeah, the scheduler code is more complicated and some of the SCHED_OTHER
policies in Linux add overhead in the tick, but that's what a clever
#ifdef is about and it should reduce the complexity of those paths for
specialized systems.

bill