Get To Know Mach, the Kernel of Mac OS X 413
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.
design is better, performance is worse (Score:5, Interesting)
Mac OS X is Mach, but it is not a Microkernel (Score:5, Interesting)
So, even though it uses Mach, you can't call it a Microkernel.
Re:Monolithic (Score:1, Interesting)
Re:Monolithic (Score:1, Interesting)
Mach pushes decisions about what it needs off until runtime instead of compile time and this translates into smaller footprints and quicker startup in most cases. Whereas linux only makes limited use of KLMs and that means most decisions have to be made at build-time and is not put off.
Re:Monolithic (Score:1, Interesting)
Basically the microkernel is the most beautiful design, I don't think anyone could disagree with that. But a monolithic kernel gets the job done, so it's not like it's bad either.
The apple design is, however, what i'd call bad. They've taken a microkernel (Mach), and implemented a monolithic kernel beneath it, to run their legacy apps!!! It's ugly!
Mac != Mach (Score:4, Interesting)
This approach doesn't make much logical sense to me, but it's what Steve and Avie wanted, and somehow, amazingly, it still just plain works.
Re:Mac OS X is Mach, but it is not a Microkernel (Score:5, Interesting)
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 (Score:5, Interesting)
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" (Score:5, Interesting)
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.
Massive microkernel (Score:1, Interesting)
I would have thought that you could implement much of Linux in userspace. Certainly file systems and the IP stack could be done easily, leaving just the hardware drivers in there. At that point, you get something that's not a great deal different from the way Mach does it.
History? (Score:1, Interesting)
Monolithic more popular, microkernel still appeals (Score:4, Interesting)
The microkernel design still appeals, though. For some things (not all) it is beneficial to move stuff out into less-privileged units. (Small) examples of this in Linux include: FUSE (for implementing non-performance-critical filesystems in Linux userspace), udev instead of devfs, moving initialisation code to the initramfs instead of being in the kernel itself...
Other systems (e.g. Dragonfly BSD) are also seeking to move functionality to userspace where possible without undue complexity and / or performance cost.
Some argue that virtual machine monitors are a useful modern equivalent to microkernels. They perform a similar function (partitioning system software into multiple less privileged entities), although they do it in a more "pragmatic", less architecturally "pure" way.
Virtual machine monitors allow multiple virtual machines to use the same hardware. They have also been used for running Linux drivers in fault-resistant sandboxed virtual machines, with performance within a few percent of a traditional monolithic design (fully privileged drivers).
The L4 microkernel is being used as a virtual machine monitor for this work by one research group, Xen has these capabilities also.
Re:They're both better! (Score:1, Interesting)
It isn't just geeks that have religious wars. Ask people that care about cars, sports, women, etc. And more choices doesn't necessarily mean that some of the choices aren't clear cut better than others.
Re:Monolithic (Score:5, Interesting)
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.
Re:XNU vs Linux. (Score:2, Interesting)
The problem with Mach (Score:5, Interesting)
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:As always... (Score:3, Interesting)
Actually, as kernels have started adding parallelism (such as SMP, clustering, etc), it becomes harder to really say exactly what sort of design a kernel really has. (Design is intrinsic and should not depend on surroundings, so does not depend on whether you are actually in a cluster, but merely whether the kernel recognizes the concept.)
Exokernels (Score:3, Interesting)
L4 performance? (Score:3, Interesting)
HURD abandoned Mach because of performance issues and is being reimplemented on L4 [l4ka.org].
If Apple had chosen L4, would it have been necessary from a performance perspective to include BSD at a peer level with the microkernel?
Is it now far too late for Apple to dump Mach?
Re:Monolithic (Score:3, Interesting)
I would disagree with you there. Apple's design may not be beautiful, but it certainly has the best of both worlds.
The BSD Layer, Memeory Managment, etc are all built inside XNU (OS X Kernel) but at the same time its still functions as a microkernel allowing things such as Kernel Extensions (Kext).
The problem with a fully MicroKernel is that its very slow because of all the context switching that has to go on between userland/and kernel land to do what is essentially kernel functionality. Apple solved this by making XNU not act as a microkernel for things such as the BSD layer.
The result is a Kernel that is less prone to panics. In Linux a bad KLM would certainly panic the kernel because it runs in the same address space as the kernel. In OS X a bad Kext would just die like anyother user space program.
As you said, it may be ugly in your opinion, but it gets the job done, it has the best of both worlds, and its less prone to panics. Now that's what I call a step in the right direction.
Re:commence the horse beating (Score:3, Interesting)
In other news: Anybody else being persistantly bugged to moderate or M2? Every single day I come back to find they want me to M2, and almost daily I find another 5 mod points.
Re:qnx does just fine with a u-kernel and message (Score:4, Interesting)
There is one very easy way to kill a microkernel's performance - force it to use a synchronous system call API (e.g. POSIX). With a synchronous system call API, a context switch is required for every system call. With an asynchronous API, the process simply writes messages into a buffer (or set of buffers for different kernel services) until it either needs to wait for a response or its quantum expires. At this point, you switch to the next context (perhaps a kernel server) and process the incoming messages. This reduces the total number of context switches (and, more importantly the number of mode switches). If you want to see good performance from QNX, then use the native system call API, not the POSIX wrapper.
Re:The problem with Mach (Score:5, Interesting)
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.
Re:commence the horse beating (Score:2, Interesting)
design AND performance better with safe kernel (Score:2, Interesting)
If the entire operating system were written in a safe language such as Java or C# ("managed" code only) then the performance impact from syscalls, virtual memory (TLB flush/lookup), complicated task switching, and extra copies of data from/to the kernel would be almost entirely eliminated. A safe language is one that does not allow arbitrary pointers.
FYI, in a linux 2.6 kernel on a 512 meg machine 4 megs is taken just to have page tables -- not even including the overhead when processes actually add pages to their memory spaces, just to have support for VM in the first place. Syscalls take ~1000x longer than normaly functions, so they are always going to be a bottleneck. And when you call a syscall that takes a data parameter (string for instance) the data is in the best case copied (in the worst case the kernel sets the address of the reading instructions in a table, then a page fault happens and the fault handler checks the table to see if the access was okay). IO using read/write is always copied at least twice, and even mmap suffers from a lot of overhead from the kernel managing the pages.
Basically kernels written in C or other archaic systems programming language are needlessly slowing down the computer a LOT. With a safe language for instance, instead of using the virtual memory to force programs to not mess with each other, they simply can't do that so the VM can be used for other things. One nice performance enhancement is to allocate all memory (objects) in a 'new' zone and use VM to track what pages have been written to; when the 'new' zone fills up only pages that have been written to are checked for references during garbage collection. So basically you could do 1 billion memory allocations of arbitrary sizes and it would take only 1 billion instructions (each allocation increments an integer and that's all). Also, "system" calls are then just normal method calls and can even be inlined, so instead of getpid() taking the time of 1000 instructions it could easily take only 1 (direct inlined access to the variable).
So lots of people will mod this down since they assume that the low-level details like cache lines are more important than oh, say, free memory management. But I got some news: a few minor tweaks and you can do all that same low-level crap in Java or managed C# and get all the benefits of a safe kernel.
Re:Monolithic (Score:4, Interesting)
To couch them in terms of Monolithic versus Micro would be like trying to classify an economy as Capitalist or Communist.
Neither economy has ever existed in it's pure form. Both descriptions also have political overtones that have precious little to do with their actualy description.
Re:They're both better! (Score:1, Interesting)
Python
Coke
C++
Mozilla
In all seriousness, though, I personally believe that the microkernel architecture is better. Whatever yields the most functionality is what's best to me, and even if performance is lower in some areas, that's okay; I'm used to making sacrifices for operating systems. After all, if all I cared about was speed, I'd still be using DOS! This is obviously not the criteria we use to choose OS's.
Nothing wrong with naming your own project (Score:3, Interesting)
That's certainly one cynical viewpoint, but is not what really happened. Linus started his own OS project and he named it as he pleased (or really those around him named it and he accepted the name). There's nothing wrong with naming your own project and then cherry picking the items you want to be in your project from the available choices. Keep in mind that the GNU folks were working on HURD at the time, and were not all that keen on the Linux kernel. So, this was not a case of someone coming along and completing the GNU project (at least, not at that time) -- this was a different OS project that shared a lot of the same code. In some ways it could be considered to be a fork, but even that is not right conceptually because the project didn't start out to be a GNU system. If the BSD utilities hadn't been under a cloud of a potential lawsuit, it may well have been that more BSD code would have made its way into the early versions of Linux (IIRC, the GNU tools were slightly buggier but more feature rich than the BSD tools at the time).
Stallman tells us the call a GNU system running on Linux GNU/Linux.
Stallman has every right to advocate that based on the perspective of someone close to the GNU project, and I have every right to ignore him based on my historical experiences with Linux from as far back as version 0.11 (I switched over from Minix to Linux, and helped Remy Card with some of the early work on ext2, so I've been using Linux for a long time).
Re:They're both better! (Score:2, Interesting)
For the rest of us, Java is much, much simpler and easier to use.
Re:commence the horse beating (Score:2, Interesting)
Slashdot works in mysterious ways.
Windows XP is a microkernel OS, too. (Score:2, Interesting)
Cutler wrote a book on it, which is still worth reading, though out of print. Microsoft has a current "XP Internals" book available from Microsoft press.
Also, Microsoft has an XP-based embeddable operating system, which eliminates many of XPs "desktop" enhancements. And of course, the excellent handheld operating systems that are the heart of Windows Mobile.
torvalds vs. tanenbaum (Score:2, Interesting)