GNU Hurd Is Still Moving, Albeit Slowly

[rvalles]

Are you telling me that modern microkernels don't need more context switches than monolithic kernels even for the simplest of tasks? I wasn't referring to the Tannenbaum vs Linus. If I read the slides correctly, simple disk access is 1 vs 4 context switches. The benefits of monolithic kernel are:

Hm, I take it you missed the point. What I meant to tell you is that microkernels aren't dead in the water because of context switch overhead as those unfortunate 1997 Mach benchmarks would have you believe (from that talk see just how little of the overhead myth is FACT and how fast L4 is compared to the Mach microkernel which fueled the myth so much) and that you shouldn't be giving up this early on the game. Linux is an awesome monolithic kernel and that's why we use it, but that shouldn't mean we should just stop there.

I can pretty much live with a single digit percent overhead for all the benefits of a pure microkernel architecture. The potential of a *free* pure microkernel architecture OS is pretty much still untapped. Notice HURD isn't even one of those (they have the drivers in-kernel). I'm interested in the promises of fault-tolerance and security which can be achieved through having a minimal, very audited and reliable critical base (the microkernel) and the isolation of parts of the system, including and specially so the drivers (typically, drivers have the highest density of bugs... they can be killed and restarted without userspace feeling it if they get stuck or they step into unmapped memory or the like... if further reinforced with iommu, hardware can even be made to DMA to virtual memory, effectively keeping the hardware from touching memory it shouldn't). See https://en.wikipedia.org/wiki/Minix3...ity_in_MINIX_3 for more details on how reliability can improve vastly through exploiting the benefits of a pure microkernel approach. It's also interesting that because of filesystems, drivers, etc. being run as processes, it maps pretty directly to smp systems, which is a very interesting alternative approach opposite to monolithic kernel's lock hell approach.

Minix3, Genode and HelenOS are all promising free pure microkernel architecture OSs that are actively developed and they've all made major key achievements in this last two years, such as getting IP networking working (helenos), finally having persistent filesystems (genode, helenos), self hosting (genode), dynamic linking and BSD-ish userspace (minix3). We're getting to the point things start to work and these systems start to be useful. Things are gonna be very interesting in the free pure microkernel os landscape in the immediate future.

[tomato]

What about on massively parallel machines? Can the parallel services run on seperate cores?

Yes, but this doesn't matter, the times of Big Kernel Lock are long since over. Linux can scale to dozens of cores.

From what I did in my CS degree Comp. Arch. course - the state of an x86 is going to be one unholy mess. Leading to slower context switches - potentially... I guess ARM might be slightly better?

True, I haven't thought about ARM. But then I hardly know anything about how an ARM CPU works so I'll refrain from speculation

Yet another person confused by the "Microkernels Are Slow" myth, which was spread as consequence of the slowness of a specific microkernel (Mach) in a popular benchmark over a decade ago...

L4 (already old) and newer microkernels are a different horse. There's a nice talk on "the microkernel overhead" at:
http://fosdem.org/2012/schedule/trac...nel_os_devroom

Are you telling me that modern microkernels don't need more context switches than monolithic kernels even for the simplest of tasks? I wasn't referring to the Tannenbaum vs Linus. If I read the slides correctly, simple disk access is 1 vs 4 context switches. The benefits of monolithic kernel are:

Easier global prediction of resource usage patterns
Read-ahead heuristics
Simpler reaction to resource pressure conditions
Mild vs. aggressive cache flushing, graceful degradation
Easier scheduler interaction
Priority boosting for interactive tasks, etc.

People are working on BFS just to make it even better on Linux because the current scheduler is deemed not good enough for interactive tasks and here we have information that on microkernels it will be even worse...

The microkernel overhead is a fact
Inherent property of the microkernel design
A price paid for the improved reliability & design

Exactly what I said before. Linux reliability and design is very good without being a microkernel. Besides, don't forget about political reasons, if the drivers could live comfortably outside the main tree, Linux wouldn't be where it is now because it wouldn't have support for half the hardware it has now!

Some quick googling: http://blog.tsunanet.net/2010/11/how...e-context.html simple calls in Linux don't even cause full context switch! A full context switch costs from 1 ms up to 4 ms! Make a thousand context switches a second an you've got a first Pentium before you.

Your pacemaker will kill you regardless of the kernel that runs on it, don't worry. (if you're interested, see Karen Sandler's article on the topic)

Yes, I watched her TED talk. The next interesting video is Adam Savage's response to the question "Why you won't do RFID and Credit Cards hackability?". Nice to see everything is fine in United Corporations of America.

[curaga]

Your pacemaker will kill you regardless of the kernel that runs on it, don't worry. (if you're interested, see Karen Sandler's article on the topic)

[rvalles]

IMHO, because of the growing discrepancy between cache speed, it's size and main memory speed, CPU context switches will only continue to be more and more expensive. That's why I'd say it looks like the microkernels will go the way of the Dodo.

Don't take me wrong, the mikrokernel idea is cool, thing is, the Linux monolithic kernel is very strictly modularized inside and plenty stable as it is. Sure, I won't put in my peacemaker, but super-ultra critical systems usually don't have to be fast, they just need to be real-time. Everything else (from watches, cooking ovens, cell-phones, desktops, servers, mainframes to supercomputers) needs to be fast or be something else first and fast second.

Yet another person confused by the "Microkernels Are Slow" myth, which was spread as consequence of the slowness of a specific microkernel (Mach) in a popular benchmark over a decade ago...

L4 (already old) and newer microkernels are a different horse. There's a nice talk on "the microkernel overhead" at:

http://fosdem.org/2012/schedule/track/microkernel_os_devroom

[bobwya]

IMHO, because of the growing discrepancy between cache speed, it's size and main memory speed, CPU context switches will only continue to be more and more expensive. That's why I'd say it looks like the microkernels will go the way of the Dodo.

What about on massively parallel machines? Can the parallel services run on seperate cores?

From what I did in my CS degree Comp. Arch. course - the state of an x86 is going to be one unholy mess. Leading to slower context switches - potentially... I guess ARM might be slightly better?

Micheal - mmm interesting "snippet"! Always good to hear about radically different kernel architectures...

[tomato]

IMHO, because of the growing discrepancy between cache speed, it's size and main memory speed, CPU context switches will only continue to be more and more expensive. That's why I'd say it looks like the microkernels will go the way of the Dodo.

Don't take me wrong, the mikrokernel idea is cool, thing is, the Linux monolithic kernel is very strictly modularized inside and plenty stable as it is. Sure, I won't put in my peacemaker, but super-ultra critical systems usually don't have to be fast, they just need to be real-time. Everything else (from watches, cooking ovens, cell-phones, desktops, servers, mainframes to supercomputers) needs to be fast or be something else first and fast second.

[rvalles]

It's good to see that there is some work being done to FOSS kernels that aren't Linux, albeit slowly.

Also, a micro/monolithic kernel shootout with GNU/Hurd and Minix against Linux and the *BSDs would prove for interesting reading.
Is there also any way to test out the perceved stability of a microkernel vs a monolithic kernel e.g. deliberately crash a module and see how well the system recovers?

And thankfully it isn't about The HURD (which has been mostly dead for a while) anymore.

We've got Minix3, HelenOS and Genode.

Minix3 and HelenOS use their own respective microkernels. Genode is a framework that supports more than one microkernel, including a few L4 derivatives.

[LinuxID10T]

I'd love to see PTS ported to Haiku and tested. Probably the coolest OS in development that I have ever seen.

[LightBit]

Is there also any way to test out the perceved stability of a microkernel vs a monolithic kernel e.g. deliberately crash a module and see how well the system recovers?

http://www.minix3.org/docs/jorrit-herder/dsn-dccs09.pdf

[intellivision]

It's good to see that there is some work being done to FOSS kernels that aren't Linux, albeit slowly.

Also, a micro/monolithic kernel shootout with GNU/Hurd and Minix against Linux and the *BSDs would prove for interesting reading.
Is there also any way to test out the perceved stability of a microkernel vs a monolithic kernel e.g. deliberately crash a module and see how well the system recovers?