Mach and caches
OK, we know that the Darwin kernel is a descendent of Mach, right? I've been told that Mach is just about the worst microkernel going for performance. The ultimate problem, I'm told, is that it needs to be able to sit entirely in the CPU's L1 cache to not incur frequent context switches.
Optimistic thought: Perhaps one of the features of the G5 is an L1 cache big enough to swallow the Darwin kernel whole. If this is indeed on the cards, I would have little trouble believing the kinds of numbers being bandied about for the G5.
So tell me: just how big is the Mach kernel? How feasible would it be to implement a suitably large L1 cache?
Optimistic thought: Perhaps one of the features of the G5 is an L1 cache big enough to swallow the Darwin kernel whole. If this is indeed on the cards, I would have little trouble believing the kinds of numbers being bandied about for the G5.
So tell me: just how big is the Mach kernel? How feasible would it be to implement a suitably large L1 cache?
Comments
PPL claims Mach kernel is not efficient because of it's modular design, unlike Linux everything's compiled to the kernel, (which makes that freaking kernel freaking huge and just face it recompiling the kernel is a very complicated and time consuming task, I don't wanna end up spending 2/3 of my time trying to fix my OS), Mach kernel tends to load thing dynamicly when it's needed.
So Linux kernel is like carrying everything with him wherever it goes.
Mach is like running back home to fetch things when it's needed.
I don't know how much performace hit will that "running home" process do, but I don't think it'll be so significant that u need to load the whole thing in Cache (anyways there will never be enough L1 cache to hold the whole kernel).
[ 11-14-2001: Message edited by: ihxo ]</p>
The result performs significantly better than standalone Mach, but alas there's no way it'll fit into an L1 cache.
As for kernel size:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
0 kernel_tas 1.8% 1:04.79 25 0 342 3.39M 0K 32.2M 335M
(...hope that lines up...)
Which one is the memory column again? RPRVT? Kernel using 3.39 megs? Eh, I was working with some people who had Linux kernels slimed down to 850k (+/- 30k) last night. But of course, they're not running as nice an OS as X.
[ 11-14-2001: Message edited by: Arakageeta ]</p>
I'd love to check into that, but got homework to do. I never know ppl check file size with Top, from what I understand normally you should do something like "ls -l"
if somehow the Linux kernel is REALLY 3 or 4 MB then that's a really great imporvement since the last time I saw it .....
large L1 caches can have a drawback that is a serious detriment to performance.
<strong>The entire kernel is always resident in memory. I figured TOP would tell me how much memory the kernel was taking. Was this incorrect??</strong><hr></blockquote>
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
0 kernel_tas 0.0% 10:04.98 24 0 969 4.69M 0K 34.4M 414M
ok ..... This is what I got from OS X's top.
Lets start the compare !!!!!
[ 11-17-2001: Message edited by: ihxo ]</p>
<strong>OK, we know that the Darwin kernel is a descendent of Mach, right? I've been told that Mach is just about the worst microkernel going for performance. The ultimate problem, I'm told, is that it needs to be able to sit entirely in the CPU's L1 cache to not incur frequent context switches.
</strong><hr></blockquote>
From what I recall, the problem with Mach is that it pays a big penalty for context switches and has to do that quite a bit since everything is abstracted out of the kernel. The advantage, is that while it's slow, it's also pretty bulletproof. Drivers can't take down the system like they can in a monolithic kernel.
But that's all right, Darwin isn't really Mach. It still uses it (since that's what Apple's NeW engineers had experience with) but they rolled in a bunch of FreeBSD stuff into kernel space as well. Sure, it probably would have been better for performance to just junk Mach, but this was a decent compromise. And instead of spending all that time on a new kernel, Apple's used it to make Quartz the speed burner we all know and love. OK, well, maybe not. At least it's pretty.
I feel like this thread has pretty much run its course. FWIW, I'll append some linkage I received from my sysadmin at work.
[quote]
<a href="http://os.inf.tu-dresden.de/L4/bib.html#phil"; target="_blank">link 1</a>
lists a number of papers
written by the l4 guys where they analyse mach and why it's slow and why
l4 is better.
Although technical, if you want to read the relevant papers that back up
my "claims":
<a href="http://i30www.ira.uka.de/publications/pubcat/Cacm.ps"; target="_blank">link 2</a>
(page 2, section on
disappointments) discusses mach and why it's slow.
<a href="http://os.inf.tu-dresden.de/papers_ps/jochen/Mikern.ps"; target="_blank">link 3</a>
(page 7, memory
effects) gives details about what I was talking about last night - the
cache problem.
<hr></blockquote>
I haven't yet browsed through these, so I can't tell you what they're like. Busy now.