Subject: Re: But why?
To: None <firstname.lastname@example.org>
From: David S. Miller <email@example.com>
Date: 10/22/1996 19:07:38
From: firstname.lastname@example.org (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
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
David S. Miller