Date: Sun, 08 Apr 2001 13:22:16 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Joseph Mallett <jmallett@newgold.net> Cc: David Kelly <dkelly@grumpy.dyndns.org>, Bzdik BSD <bzdik@yahoo.com>, freebsd-chat@FreeBSD.ORG Subject: Re: Clash of Titans - Tale of two Morons Message-ID: <200104082022.QAA22402@sheffield.cnchost.com> In-Reply-To: Your message of "Sat, 07 Apr 2001 00:33:24 EDT." <Pine.BSO.4.21.0104070032120.8889-100000@aphex.newgold.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Actually, Linus didn't really say much about OS X/Apple, he was more or
> less saying that mach is crap (actually, those are pretty much his exact
> words) and that apple was stupid for building on top of it. Of course,
> he's a guy who almost failed an OS Design class, so maybe his opinion
> doesn't matter <g>
I don't know what Torvalds had in mind but there is some
evidence that Mach based OSes are slower compared to
monolithic ones. A while ago there was a paper that showed
MkLinux (Linux running on top of Mach) was quite a bit slower
than native linux on the same hardware. Henry Massalin's
thesis on Synthesis shows another comparison of a native Unix
(Sony NEWS) and a mach based unix (NeXT) on the same speed
h/w, where Mach has 2 to 3 times the overhead for syscall and
ctx switch.
You will also see criticism of Mach from people working on
more modern microkernels like L4. They point out that `1st
generation' ukernels like mach are not so small or fast or
flexible. They too ported Linux to run as a user process on
L4 and found that L4-linux was still 5% slower than a native
linux.
Emulating Unix API does hobble a ukernel since a couple of
user/supervisor mode boundary crossing are needed for each
system call. If you push more functinality in in the
ukernel, it starts getting bloated and you lose some benefits
of a ukernel (extensibility, fault isolation, ability to
change or adapt behavior or policy).
Note that QNX, a commercial ukernel OS (started way before
someone coined the phrase `microkernel'), has evolved very
nicely over the last 15 to 20 years and yet remained very
small and efficient. ISTR the kernel fit in 8K~12K on x86.
L4 is also quite small (under 12Kbytes) and is written in
assembly language. Fiasco (also done at the Dresden Uni. of
Tech.) implements the L4 API and is written in C++ and uses
non blocking synchronization. Follow links from
http://os.inf.tu-dresden.de/L4
if you want to read about these. There are a number of
other ukernels worth reading about (google for microkernel).
There are a lot of neat ideas in these OSes but it seems that
ultimately a lot of the modern OS research goes nowhere once
a few PhD theses get generated and these students move on to
new things. The ubiquitousness of Unix does not help either.
Even a very nice os like Plan9 has a hard time dethroning
Unix. Speaking which, you may also want to read Rob Pike's
`System Software Research is Irrelevant' -- though i don't
think the situation isn't all that bad.
Bringing this back to FreeBSD, it would be neat to see the
BSD API implemented on top of a tiny ukernel even if that
meant a few % slowdown. The FreeBSD kernel is grown quite a
lot over the years and while I applaud and marvel at the
amount of new stuff added and old stuff speeded up, every
time someone adds a new feature I keep thinking does it have
to be in the kernel? Perhaps -current has become so fragile
partially because of the kernel size and interdependency of
modules. Such rearchitecting would be fun but a big task....
-- bakul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104082022.QAA22402>