or Connect
AppleInsider › Forums › Mac Hardware › Future Apple Hardware › Mach and caches
New Posts  All Forums:Forum Nav:

Mach and caches

post #1 of 10
Thread Starter 
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?
post #2 of 10
Mach kernel is a small Microkernel (about 10-20 times smaller than Linux kernel), but I don't think it needs to be loaded to L1 cache in order to improve performace.

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>
post #3 of 10
Darwin doesn't run on top of a distinct Mach microkernel. Mach is integrated into the Darwin kernel, which is monolithic, along with bits and pieces of NuKernel and some new code to enable Classic.

The result performs significantly better than standalone Mach, but alas there's no way it'll fit into an L1 cache.
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #4 of 10
Recompiling the Linux kernel isn't all that hard. Just use xconfig for a nice GUI interface with help. ...however... I am told xconfig isn't used everywhere yet.

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>
post #5 of 10
"RPRVT(delta) the resident private memory"

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 ..... 4 years ago ... I was able to compile a 6x MB kernel with nearly everything including microwave oven in it .....
post #6 of 10
Nevertheless,

large L1 caches can have a drawback that is a serious detriment to performance.
rm -rf /bin/laden
Reply
rm -rf /bin/laden
Reply
post #7 of 10
The entire kernel is always resident in memory. I figured TOP would tell me how much memory the kernel was taking. Was this incorrect??
post #8 of 10
[quote]Originally posted by Arakageeta:
<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>
post #9 of 10
[quote]Originally posted by boy_analog:
<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.
post #10 of 10
Thread Starter 
Thanks for the info!

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.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Future Apple Hardware
AppleInsider › Forums › Mac Hardware › Future Apple Hardware › Mach and caches