GNU Hurd Is Still Moving, Albeit Slowly

[phoronix]

Phoronix: GNU Hurd Is Still Moving, Albeit Slowly

Since last week when writing about the LLVM/Clang compiler being ported to GNU Hurd, readers have asked via the forums, email, etc about the state of this open-source kernel backed by the Free Software Foundation. GNU Hurd and its Mach micro-kernel continue to be developed, just not at a rapid pace like the Linux kernel...

http://www.phoronix.com/vr.php?view=MTI3OTE

[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?

[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

[LinuxID10T]

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

[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.

[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.

[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...

[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/trac...nel_os_devroom

[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)

[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.