From: lm@neteng.engr.sgi.com (Larry McVoy)
   Date: Tue, 22 Oct 1996 14:39:10 -0700

   In the Linux world, it works upside down from that.  The
   performance weenies think about were cache misses are likely to
   happen and go get rid of them.  New features are added in such a
   way that they introduce no new cache misses, or at least no new
   unexpected ones (sometimes ya gotta do what ya gotta do).  But the
   point is that the OS people have a mental image of the critical
   code path and what that code path costs.  Additions to the code
   path are heavily discouraged.

So true.  Especially as of late my stream of consciousness has been
"geese, it has been almost two days since I was able to suck a couple
hundred cycles out of a major critical code path, I'm slacking off
again."

   So get lmbench numbers for a Microkernel.  QNX posted theirs in
   days after I released the benchmark.  It's been over a year (maybe
   two) and no results from the uKernel camps.  Why not?

Probably because QNX is one of the few microkernels that is more
action than lip service I'd imagine.  But I could be wrong.

I just got some lmbench numbers on the same hardware, it pitted up
NetBSD, Linux as an OSF Microkernel server, and "real Linux".  NetBSD
sucked rocks and was worse than Linux as a MicroKernel server, and
"real linux" was twice as fast as the OSF MKlinux server.  ("real
linux" was like 4 times faster than netbsd for many critical
operations).  Oh yes, system calls via RPC, what a win.

   Wow, look, I speak a foreign language, I speak the Linux dialect of
   Kernel :-)

Congrats ;-)

David S. Miller
davem@caip.rutgers.edu