[flame] Re: Benchmarks... (fwd)

Ingo Molnar (mingo@pc7537.hil.siemens.at)
Tue, 4 Nov 1997 19:17:33 +0100 (MET)

On Tue, 4 Nov 1997, Adam 'WeirdArms' Wiggins wrote:

> The Performance of µ-Kernel-Based Systems.
> Hermann H&aumlrtig, Michael Hohmuth (Dresden University of
> Technology), Jochen Liedtke (IBM, Yorktown), Sebastian Sch&oumlnberg,
> and Jean Wolter (Dresden University of Technology).
>
> available at http://os.inf.tu-dresden.de/pubs/sosp97/
>
> [...]
> mach. The L4 kernel instead suffers a really minimal performance
> degradation (few percent) [...]

i found the above article largely misleading.

the L4 'kernel', (based on info in the above URL) in it's current form
IMHO is just a binary emulation library, a kind of 'system call
multiplexing library'.

this has been done for ages within the Linux kernel. (binary compatibility
with Solaris, Dec OSF/1, or the iBCS interface). And it costs much less
than 300 cycles ...

It's not a single step closer to real microkernel goals, 'multiple OSs on
a single system'. For now it's just a binary emulation library, which adds
some 300 cycles overhead to normal Linux system entry latency ... not a
thing i'd like to have personally ...

then there is a 'proof' in the article, about how 'powerful' micro-kernels
are: "6.1 Pipes and RPC". It is simply a weak point of Linux: large
bandwith pipes. NetBSD has mmap()-ed pipes, so this is nothing that is
inherently microkernelish. Look at how fast Linux does a 'dd if=/dev/zero
of=/dev/null bs=1024k', i've measured 9000 MBytes/sec actually ... pipes
are not yet MMU enhanced, i have this in my queue ... [and note that if
you need large bandwith you shouldnt go over a pipe in the first place, or
you are a bad application programmer ...]

Then another comment in the article: "The emulated pipes are POSIX
compliant, except that they do not support signaling". Oh, this is
again speeding up things by removing features/generality ...

please, please. Linux is _not_ 'monolithic'. It has a largely flexible
internal architecture, which is very close to microkernels. Do not waste
effort, improve Linux, there is no sense going over _two_ interfaces and
eating the latency overhead. Please, show me a _single_ point where Linux
has proven to be inflexible.

and important issues like how to coordinate hardware-resource sharing
between the Linux single server and the microkernel are carefully omitted
...

-- mingo