Get To Know Mach, the Kernel of Mac OS X

An anonymous reader writes "Linux is a kernel, not an operating system. So what is Mac OS X's kernel? The Mach microkernel. The debate around Monolithic (Linux) and Micro (Mach) kernels continues, and there is a great chapter online about the Mach system from the very good book 'Operating System Concepts'. Which design is better? I report, you decide." Warning: link is to a PDF.

Comments

design is better, performance is worse

[iggymanz]

The modular design of microkernels makes for easier design & debugging, and with some designs the freedom to make user space services that can only be in privileged space in monolithic designs, but does one want to pay the overhead for all that message passing? Now that we are getting into parallel processing at the consumer level with multicore and hyperthreaded chips, maybe the answer is yes.

Mac OS X is Mach, but it is not a Microkernel

[dumbnose]

Mac OS X uses Mach, but it also uses a FreeBSD kernel and compiles them together. This eliminates the runtime characteristics of a Microkernel. This is actually quite common.

So, even though it uses Mach, you can't call it a Microkernel.

Re:Mac OS X is Mach, but it is not a Microkernel

[arete]

I suppose it's possible I'm underinformed, but I believe the "BSD subsystem" of OSX is not compiled "into the kernel" and is entirely a compatibility layer on top of it.

I suspect this is exactly how to never violate the microkernel design and still have BSD compat.

Re:qnx does just fine with a u-kernel and message

[RickHunter]

1. QNX has been multi-platform for quite a while.
2. QNX uses shared memory to pass messages. Its message passing is very lightweight, and the resulting performance is far better than Linux.

In this day and age, there is no reason to use a macrokernel unless your hardware lacks the features needed for a microkernel. QNX has proved this quite nicely.

Not a "compatibility layer"

[argent]

It is based on Mach with a BSD compatibility layer

It's not just a "compatibility layer". A Mach system consists of multiple servers providing services to each other and to applications. The BSD server in XNU is an essential part of the system... it's the ringleader, and calls the shots from boot onwards.

Re:Monolithic

[jd]

The modules may be loaded into the kernel proper, but that does not make Linux necessarily monolithic, as the bindings are necessarily on-the-fly and the failure of a given module does not automatically mean the failure of the kernel as a whole.

mkLinux is not the only microkernel Linux - L4Linux is still maintained and is much more advanced. Nor are these the only Linux kernels to run in userspace - UML Linux, for example, does just fine. It is not clear where XEN fits into the picture.

All in all, though, the situation with Linux is actually a highly complex one, and should not be regarded as being definitely anything.

The problem with Mach

[Maury Markowitz]

Although interesting, Mach was developed at a university and shows a huge number of problems as a result. Notably performance is terrible, due largely to the IPC performance. When people actually tried the "collection of servers" operating system in Mach 3, it was clear it was simply not a workable solution. Workplace OS, Star Trek and any number of other OS's died as a result.

What's sad about this is that the failure of Mach tainted ALL ukernels. By the mid-1990s the idea was basically dead. But what an idea! Don't have your machine on a network? Simply don't run the network program. Using a diskless system? Don't run the disk server. Don't want _VM_... no problem. You can use the exact same OS image to build anything from a minimal OS for a handheld to a full-blown multi-machine cluster, without even compiling. No pluggable kernels, no shared libraries, no stackable file systems, nothing but top and ls.

But it just didn't work. IIRC performance of a Unix app on a truly collection-of-servers Mach was 56% slower than BSD. Unusable. Of course you can compile the entire thing into a single app, the "co-located servers" idea, but then all the advantages of Mach go away, every single one.

Now, given this, the question has to be asked: why anyone would still use it? Don't get me wrong, there are real advantages to Mach, notably for Apple who ship a number of multiprocessor machines. But the same support can be added to monokernals. Likewise Apple's version has support for soft realtime, which has also been added to monokernels. So in the end the Mac runs slower than it could, and I am hard pressed to find an upside.

Of course it didn't have to be this way. The problems in Mach led from the development process, not the concepts within. As L4 shows, it is possible to make a cross-platform IPC system that is not a serious drag on performance. And Sun's Spring went further than anyone, really re-writing the entire OS into something I find really interesting, and still providing fast Unix at the same time. I'd love to see someone build Mac OS X on Spring...

Re:The problem with Mach

[Animats]

Although interesting, Mach was developed at a university and shows a huge number of problems as a result.

Sad, but true. The developers of Mach chose to start with BSD and tried to hack it into a microkernel, one section at a time. This was a flop. Mach 2.5, which Apple uses, is basically BSD with some Mach features. Mach 3 is more of a microkernel, but is so awful that nobody uses it.

There are really only two microkernels that work - VM, for IBM mainframes, and QNX. In both cases, incredible care was put into getting the key primitives - interprocess communication and scheduling - right. If those are botched, the system never recovers.

Mach suffered from too much "cool idea" syndrome. There's too much generality in key primitives that need to work fast. Message passing has too many options. The ability to build heterogeneous multiprocessor clusters out of whatever you have lying around complicates the simpler cases. And sharing memory across the network isn't worth the trouble.

It's clear from VM and QNX how a microkernel should work. Interprocess communication and scheduling need to play well together. Interprocess communication primitives should be like subroutine calls, not I/O operations. Try for an overhead of about 20%, and don't get carried away with the "zero copy" mania. Organize the I/O system so that the channel drivers that manage memory access are separate from the device drivers that manage the device functions.

This is how you get uptime measured in years.