Embedded.com Guest Editorial
Microkernels rule!
Gernot Heiser
6/25/2008 11:50 PM EDT
Clearly, there's a lot of skepticism.
Do microkernels suck? In a nutshell: no, they rock--if they're well designed and implemented. I will elaborate.
Microkernels, first invented around 1970, are based on the idea of moving the operating system's services out of the kernel (the code that runs in the processor's privileged mode) into user-mode servers. Microkernels were en vogue in the 1980s; it seemed as if everyone was building one. And, as with many fashionable technologies, their proponents promised much and delivered little.
Mach, an OS that was widely used as the basis of systems, ran into serious performance problems, and its contemporaries (like Chorus and QNX) weren't much better. There were spectacular failures, none more so than IBM's Workplace OS, which cost the company a cool two gigabucks. Others, like the Mach-based OSF/1 and Next operating systems, ended up moving most OS functionality back into the kernel. This is how Mac OS X functions today; it has given up any pretense of being a microkernel OS.
Needless to say, the experience with Mach and others created a bit of an image problem for microkernels (which didn't stop the GNU Hurd from repeating the mistakes of the past). However, back in 1993, Jochen Liedtke demonstrated that these performance problems weren't inherent in the microkernel concept. His L4 microkernel ran rings around the competition, outperforming Mach and QNX by factors of 5 to 20 in the cost of the critical IPC primitive. In an analysis of Mach, he showed that the poor performance was a result of excessive size (about 300 kernel APIs and 100s kLOC is certainly not "micro").
Liedtke showed that minimality was critical and formulated what is now the accepted definition: a microkernel only contains code that must execute in kernel mode; everything else should run as user-mode programs. He also outlined design principles for flexible, high-performance microkernels.
|
|
|
|
|
c_a_kozak
6/24/2008 12:50 PM EDT
Hi,
Nice article. I am working on Symbian OS which also happens to be microkernel based. And the success of Symbian in the mobile industry stands proof for your claim as well!!!!
Sign in to Reply
Paul L at QNX
6/25/2008 12:07 PM EDT
I have a hard time understanding: 1) why the author would state that QNX isn't much faster than an OS with "serious performance problems" and 2) why he would imply that QNX exists in the past tense. As for the first point, independent tests have repeatedly demonstrated QNX's superior performance (see http://www.qnx.com/download/group.html?programid=7795). As for the second point, QNX is used in millions of embedded systems, including brand-new cars from almost every automaker on the planet. You don't become popular in the automotive market (or the nuclear controls market) by offering sub-par performance.
I work for QNX, so yes, I'm biased. But then, so is the author, as his company also offers a microkernel OS. That said, we can both agree that microkernels rule. :-)
Sign in to Reply
p(i)g
6/26/2008 7:55 AM EDT
I also got the impression that QNX is alive and (maybe)well, and I don't work for QSSL. I'm going to give a look at OKL site, but the often cited "virtualized Linux" over LK (if I understand correctly) seems to suggest it's their way to have hardware support (in which case I vote for QNX time-proofed harware driver development style, user space resource managers)
Sign in to Reply
Dr Gernot
6/26/2008 9:09 PM EDT
Hi Paul,
The past-tense reference to QNX is to the time when microkernels in general were experiencing performance problems (this is the early '90s). There is no implication that it no longer exists.
The performance problems, incl QNX's, are well documented, see the paper referenced in the article. It shows IPC cost in QNX to be 5 times those of L4 on the same hardware.
In fact, measurements performed by my students on the latest version of QNX indicate that this performance gap has in fact increased (note I'm referring to average-case, not worst-case performance).
It is true that QNX is commercially successful, and my claim would be that this is mostly a result of the high robustness it gets from the microkernel approach (and I specifically mention QNX in this context later in the article).
However, this has nothing to do with performance, In fact, in the performance-critical markets (battery-powered mobile devices where overheads cost battery lifetime) QNX plays no role whatsoever. OKL4, on the other hand, is deployed in some 100 million mobile phones.
In summary, QNX has convincingly demonstrated that the robustness benefits of microkernels are real. OKL4 has convincingly demonstrated that performance is no longer the Achilles heel of microkernels.
Sign in to Reply
Dr Gernot
6/26/2008 9:16 PM EDT
Hi p(i)g,
Virtualization is just one use case of OKL4. It has the same philosophy as QNX (specifically no drivers in the kernel, all services at user level). Both are true microkernels.
Sign in to Reply
Paul L at QNX
6/27/2008 12:49 PM EDT
Hi Gernot. Thanks for responding. There is a *huge* difference between claiming "my IPC is faster than yours" and claiming that QNX has performance problems. Guitarist A might be a faster guitarist B when playing a specific run, but they can both be world-class virtuosos. Also, to say that QNX plays no role in performance-critical applications totally mystifies me. In most QNX systems, performance is a major factor -- and always has been. We obviously have different definitions of "performance-critical".
Sign in to Reply
Dr Gernot
6/28/2008 12:14 PM EDT
Well, IPC is the fundamental operation in a microkernel, everything else is implemented by IPC. If IPC is slow, the microkernel-based system will be slow.
Our measurements indicate that lmbench performance of QNX is significantly worse than that of Linux virtualized on OKL4 (which is a test that disadvantages OKL4, a native POSIX implementation would be expected to perform better).
Sign in to Reply
Paul L at QNX
6/28/2008 2:15 PM EDT
I point again to the independent measurements of QNX performance and to the millions of performance-critical systems that run QNX -- including systems that both you and I rely on every day.
Cheers,
- Paul
Sign in to Reply
Dr Gernot
6/29/2008 1:30 AM EDT
ECUs in cars etc aren't really performance-critical, they are generally over-provisioned for safety. Battery-powered mobile devices are. And performance comparisons with Linux (which isn't a real-time OS no matter what people say) aren't all that meaningful.
Let's wait until my student's results are ready.
Sign in to Reply
Mike Perkins
7/2/2008 9:17 AM EDT
Can we please raise our journalistic standards to not include phrases like "they suck?" There are other ways to express ourselves.
That said, I'd like to mention that software engineers at my company about 15 years ago developed something we called The Un-Kernel for a large (at the time) high-reliability embedded product. It did what it needed to do quite well.
Sign in to Reply
dad4x
4/12/2011 1:02 AM EDT
"On modern processors and a high-performance kernel like L4, that overhead is less than a microsecond per service invocation. For most services, this is negligible."
Hmmm, that's 1000 or so instructions worth of time not doing any useful work. Whether that is "negligible" is worthy of more than just bland assertion, I think.
-dB
Sign in to Reply