[gillianseed]

In the most recent talk I saw with Tanenbaum regarding Minix and performance, he mentioned a 20% decrease compared to monolithic kernel based systems, which he himself was happy to sacrifice for the greater system stability it offers.

Of course, the big standout for me has always been that if micro-kernel based systems of today are just as, or close enough in terms of performance, why aren't we getting any benchmarks showing this off ?

It would be fantastic promotion to show your system running against Linux or the BSD's and performing as well or near as well in heavy workloads while at the same time offering the great stability of typically being able to restart modules should they crash and thus not take down the whole system.

The micro-kernel vendors should be shouting it from the rooftops, 'here are the benchmarks!', but they don't as far as I can tell.

The last time I saw a modern micro-kernel vs modern monolithic comparison was probably this one way back in 2007, and in this Minix 3 did not do very well against Linux.

http://lwn.net/Articles/220255/

[aidenn0]

Having worked with a modern microkernel, 20% is a fair number for device drivers that are not doing bulk data transfers, if you both avoid shared memory and are on an platform that lacks hardware features for accelerating such things, though the OS's choices of IPC mechanisms become very important, and any one number is always wrong.

A microkernel offers you the flexibility to choose this though. On linux, I write all my programs to run as processes. If I find I'm getting performance bound by system-call overhead, I can convert part of the program to a kernel module, to eliminate that.

Microkernels extend this concept into the OS. If you find a bottleneck that is truely bogging you down, you can fix it. After working with microkernels for a while, the monolith way feels like the equivalent of starting every application as a kernel module rather than an independent process.

Lastly I think a microkernel where a single module crash can hang the entire system is still superior to a monolithic kernel. The worst bugs aren't crashes, they are the ones where a bit of memory got corrupted and odd things just start happening. The more address spaces you have, the more localized the behavior of such bugs will be.

[nanolith]

Well, most microkernel vendors have niche markets that aren't directly competing against Linux. Minix 3 is a bit of an outlier. Although it is a desktop and "server" OS like Linux, it's really meant to be more of a teaching OS than anything else.

If you want to compare microkernel operating systems, look at QNX, L4, Windows CE, etc. These are used in embedded and RTOS spaces where performance is critical. They seem to hold their own pretty well, and running in systems where Linux would not be a good alternative due to size and porting cost.

[Gibbon1]

In a lot of these cases a small foot print and guaranteed latency is vastly more important than raw speed. As in with a task that runs 20 times a second, it's not important that it finishes in 1 ms or 3 ms, but having the system go away for 500ms is not acceptable.

[nanolith]

I guess I should have clarified that "reliable and predictable" performance is critical. In practice though, these systems have fast enough context switching.

I agree with you that "fast enough" is the only metric that matters here.

[justincormack]

Minix3 is not designed as a teaching OS, it is designed for production use, primarily for embedded systems.

[carussell]

Not really.

Every now and then there's this thing that happens where somebody runs across some surface-level comment by some fairly authoritative source, arrives at a mistaken interpretation of it, and that interpretation just happens to be the one that gets widely repeated, and thus an error enters into the public awareness on that topic. That seems to be what happened with the MINIX-and-embedded-systems meme that keeps showing up.

MINIX tried to position itself as a good candidate for use on embedded systems—in addition to its then-current primary (read: only viable) use as a PC operating system. It never really ended up happening. The idea seems to have been to use the grant money as a catalyst to get it in shape so that it looks attractive and can get commercial adoption at the cusp of the move to a post-PC world, and then it will be sufficiently dug-in with a few parties, enough so that it would see sustained development in your typical open source fashion.

The reality is, it didn't really pan out (NB: not necessarily as a result of its essential microkernellyness), they burned through several million Euro that all seems to have gone towards paying developers and putting very little towards project management, and today nobody is doing serious development on it, save for something like one grad student who mostly continues to work on it in the course of his research. In its current state, it has rudimentary support for something like two boards (from the BeagleBoard line), and its best supported platform, relatively speaking, is still PCs, although its support there can itself only really be called so-so by a more absolute metric.

(Caveat: MINIX is BSD licensed, so it's possible there's somebody out there getting lots of mileage out of it and/or doing spectacular things.)

To be fair, even as a teaching OS, though, things do look rough nowadays. In the past, the way things worked was, Tanenbaum would take the sources, clean it up and trim some of the parts that wouldn't be covered in the Operating Systems book, and then ship it. With the current state of the code, after the quality of the changes that occurred in the aforementioned process, if he were to try to do the same for a 4th edition of the book, he's going to have a lot of work ahead of him.

All in all, given the current state of the project, the answer to the question, "What is the best use for MINIX today?" is "For research."

I say all this as someone who has got some patches for cleaning up and consolidating a bit of the bootstrap code for ARM and x86, but with nowhere to effectively send them.