Slashdot Mirror

What's disappointing is that the Hurd kernel was such a dud. They've been trying to write a microkernel for a decade. Unfortunately, they started with the Mach interprocess communication model, and never escaped.

Well, they've learned the lesson and are beginning to switch the system to the much simpler and faster L4. Problem is that it doesn't have as much features as Mach (which is not a surprise, really, if you know Mach), and replacing them in user space is going to take some time. Still, the work is on, and in two years or so...

Neal H. Walfield is in charge of porting the Hurd to L4. He's waiting for the Pistachio implementation to be released (which is promised to be soon).

L4 is independent of the Hurd. It's a research-project started by Prof. Jochen Lietdke. It's performance seems to be good (unlike Mach's), and its structure is very different from that of Mach, so the Hurd developers want to port the Hurd to L4.

Actually, microkernels have the potential to increase the performance of applications such as databases and multimedia.

A very good read that I recommend to anyone interested in operating systems is Towards Real Microkernels by Jochen Liedtke. It explains the advantages of microkernel-based systems, what is wrong with older microkernels like Mach, and why current second-generation microkernels are better.

Actually, when distinguishing between implementations of the Hurd on different microkernels, we ususally say Hurd/Mach versus Hurd/L4. This is consistent with GNU/Linux and GNU/Hurd, ie. HigherLayer/LowerLayer.

OSKit-Mach is just a superior implementation of Mach, so we'd still call it Hurd/Mach if we needed to make a distinction.

Real improvements to the Hurd will come with the eventual port to the microkernel which is much superior to Mach (and the answer to current anti-microkernel FUD).

The short version of the story is that it is an object oriented paradigm in which every class is a process and every instance is a thread. It needs hyper fast messaging and process/thread swapping. No other OS will do that.

Someone obviously hasn't done their research:
L4
EROS

Both of these kernels are vastly superior to anything they will be able to build for message passing and context switching speed.

Opening up the source code for the QNX Neutrino kernel would be excellent for many companies, except for QSSL which would probably go bankrupt soon afterwards.

Such agreements do not need to convince you, but Consumer Electronic Giants. ;) As a developer or consumer this is what mainly should matter to you. :)

ubiquitous computing

Yeah, NeXT was waayyy ahead of it's time. The same thing goes for apple, just somewhat less so. As my friend Eric said, "Apple's problem is that it tries to sell stuff that's ahead of it's time to people who don't appreciate it." I REALLY like Apple hardware, and if I weren't a poor college student, I'd have a G4 machine (or a used UltraSPARC). Did anyone notice that the slashdot article last week about the dual CPU machines for artists had some benchmarks with dual 400 MHZ G4s lagging not so far behind dual 1.7 GHz Xeons?

Now, if only Apple would throw a more modern micokernel (caugh port l4 caugh) under Darwin, I'd pretty much be forced to sell my soul for a new machine. Provided of course, the kernel was still open source.

Microsoft wanted NT to be a microkernel OS, but they couldn't quite pull it off for performance reasons. Apple managed to pull it off with an old microkernel. Imagine how OS XI would fly with a higher performance (and smaller and simpler) micokernel under the hood.

Warning: Micokernel rant
I don't mean to start a flame war, but Mach has way too many features to make implementation and optimization easy. Small micokernels rock! I had to benchmark the memory latency of several systems for my systems design class. I chose my personal box running Linux and my personal box running QNX for two of the systems. Linux showed the expected gradual transition from cache latency to RAM latency as the size of the buffer used in the benchmark approached the cache size. However, under QNX the memory latency managed to stay very low until the benchmark buffer size got very close to the cache size, and then there was a rapid transition to the RAM latency. This shows that small microkernels are more resistant to cache thrashing (yes, I did boot Linux into runlevel 2 and kept applications to a minimum) because you have fewer bites of kernel code that are continually pushing stuff out of the cache. I'm not sure why the user-level servers didn't offset this. Maybe QNX tries to buffer system requests and run the user-level servers in batches for performance reasons. In any case, there was a marked difference in the benchmarks on the same hardware. If you combine this with L4's very fast messge passing, modern microkernels make a lot more sense than older microkernels like Mach. If you've got x86 or ARM hardware, check out the L4Ka site. Uwe posted an updated snapshot of the Hazelnut implementation of L4 today. (Supposedly the IPC is blazingly fast. I don't know how they teaked their C to be faster than Jochen's x86 assembly kernel but they did it. I suppose that with only about 11 system calls, you have a lot of time to tweak them all.) It's been almost a year since the last snapshot was posted, but the mailing lists show that devlopment is going strong. L4 really shows the elegance of simplicity. It has a very small set of well designed features that are very flexible and powerful, which allows L4 to get away with fewer than 10% of the number of system calls used by Mach.

First, if you've designed your system in a way that you have to copy large amounts of data between time critical components, you've been doing a terrible job at the design board. Why not share/map the data between different components instead? Second, copying data in and out of the kernel is usually completely unnecessary. The kernel can simply copy the data from one address space to another (no extra copy cost and cache polution by having a temporary copy buffer inside the kernel).

If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).

Now, why do you assume that you're going to pay for it in cache misses. True, there may be some cache misses incurred by context switches, but a properly designed kernel can get this down to 12 misses or less (i.e., the kernel touches 12 cache lines doing an IPC between two address spaces, cache lines which may flush out some of the working set of the applications).

The limitations are going away in the upcoming L4 Version 4 API without hurting the performance. Actually, intra-AS IPC is going to be 10 times faster (~15 cycles).

The limitations are going away in the upcoming L4 Version 4 API without hurting the performance. Actually, intra-AS IPC is going to be 10 times faster (~15 cycles).

Strange. Last time we did measurements here (L4Ka), we ended up with 99 cycles on a 450Mhz PIII to send a message from one process to another. If one has communication within a single task the numbers are an order of magnitude lower (i.e., about 15 cycles).

Power:
Methane powered fuel cell, which provides for at least a months worth of continuous use.

The Screen:
Light emitting polymer screen is good here. Nice choice. The screen should also have some mechanism for eliminating finger grease automatically.

Form Factor:
A6, there should be no border, so that the screen takes up the entire front. Perhaps with fanned screens like the Psion Protoypes. (can't find a link)

Communications:
An array of Software Defined Radios, allows the device to keep in touch with the outside world. Depending on your current usage, they may be configured for Wireless Ethernet, BlueTooth, 3G+, TV, Radio etc. No need for multiple cards and slots. When a bug or security risk is found in any of the protocols, a simple software patch will fix the problem.

When data is huge, perhaps something like Infiniband over fibre optic would be useful.

Input:
Touch screen will be supported, along with a slide-out or otherwise concealed keyboard for when you actually want to enter some data. Voice recognition would also be nice, but only when your on your own.

CPU
Since were obviously way off into the future here, I would like a micro-distributed memory architecture, with approx 32 CPUs, each with at least 64 MB of memory. The CPU should probably be something like a 64bit ARM, running at whatever clockspeed is fashionable at the time. See this for similar stuff. The interconnects between CPU modules should use something like AMD's HyperTransport

OS
For linux fans, the CPU the architecture would support a micro-Beowulf style mode of operation.

For me, I'll roll my own Actor Model based system, running on a microkernel, like L4 but with better real-time response. Built in cryptography will keep ALL comms secure.

Substantiated claims? Ever heard of Jochen Liedtke and the L4 microkernel? He and many other researchers wrote the following papers if you'd care to read them:

The performance of microkernel based systems

Achieved IPC performance

Microkernels must and can be small

On Microkernel construction

Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces

If you'd like a breakdown, here it is: x86 sucks for context switch times for two main reasons, a)user/supervisor transition times are an order of magnitude slower than other architectures and b) a poorly designed TLB cache results in a flush whenever a context switch occurs(only if the address space changes of course). Any advantage the x86 architecture gains by having few registers is lost(and then some) by these other factors. This can be readily seen in operating systems and kernels that rely heavily on context switching such as microkernels.

For quick and dirty evidence: here. That's a link showing context switching times for Linux running on an 850 MHz PIII. The times typically hover around 12 microseconds. The papers I linked to above show achieved IPC times for L4 which are steady around 3 microseconds on much lower-end hardware. That's IPC, not just context switching, ie. context switch and copying data to another address space. The L4 teams have tweaked their implementation as fast as it can go on x86, and have achieved performance an order of magnitude higher than Linux(at least in this area). This demonstrates some pretty solid expertise. Given this, they say admit that x86 is very poor in this respect and a great hindrance in designing a good operating system. I believe some of the papers briefly discuss other architectures, but most of the focus is on the x86 platform because it's such a performance problem.

P.S. the fact that the x86 is register poor is not a good thing. Having two few registers to manipulate data is often a hindrance. Saving 3 times as many registers doesn't take that long anyhow.

Substantiated claims? Ever heard of Jochen Liedtke and the L4 microkernel? He and many other researchers wrote the following papers if you'd care to read them:

The performance of microkernel based systems

Achieved IPC performance

Microkernels must and can be small

On Microkernel construction

Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces

If you'd like a breakdown, here it is: x86 sucks for context switch times for two main reasons, a)user/supervisor transition times are an order of magnitude slower than other architectures and b) a poorly designed TLB cache results in a flush whenever a context switch occurs(only if the address space changes of course). Any advantage the x86 architecture gains by having few registers is lost(and then some) by these other factors. This can be readily seen in operating systems and kernels that rely heavily on context switching such as microkernels.

For quick and dirty evidence: here. That's a link showing context switching times for Linux running on an 850 MHz PIII. The times typically hover around 12 microseconds. The papers I linked to above show achieved IPC times for L4 which are steady around 3 microseconds on much lower-end hardware. That's IPC, not just context switching, ie. context switch and copying data to another address space. The L4 teams have tweaked their implementation as fast as it can go on x86, and have achieved performance an order of magnitude higher than Linux(at least in this area). This demonstrates some pretty solid expertise. Given this, they say admit that x86 is very poor in this respect and a great hindrance in designing a good operating system. I believe some of the papers briefly discuss other architectures, but most of the focus is on the x86 platform because it's such a performance problem.

P.S. the fact that the x86 is register poor is not a good thing. Having two few registers to manipulate data is often a hindrance. Saving 3 times as many registers doesn't take that long anyhow.

Substantiated claims? Ever heard of Jochen Liedtke and the L4 microkernel? He and many other researchers wrote the following papers if you'd care to read them:

The performance of microkernel based systems

Achieved IPC performance

Microkernels must and can be small

On Microkernel construction

Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces

If you'd like a breakdown, here it is: x86 sucks for context switch times for two main reasons, a)user/supervisor transition times are an order of magnitude slower than other architectures and b) a poorly designed TLB cache results in a flush whenever a context switch occurs(only if the address space changes of course). Any advantage the x86 architecture gains by having few registers is lost(and then some) by these other factors. This can be readily seen in operating systems and kernels that rely heavily on context switching such as microkernels.

For quick and dirty evidence: here. That's a link showing context switching times for Linux running on an 850 MHz PIII. The times typically hover around 12 microseconds. The papers I linked to above show achieved IPC times for L4 which are steady around 3 microseconds on much lower-end hardware. That's IPC, not just context switching, ie. context switch and copying data to another address space. The L4 teams have tweaked their implementation as fast as it can go on x86, and have achieved performance an order of magnitude higher than Linux(at least in this area). This demonstrates some pretty solid expertise. Given this, they say admit that x86 is very poor in this respect and a great hindrance in designing a good operating system. I believe some of the papers briefly discuss other architectures, but most of the focus is on the x86 platform because it's such a performance problem.

P.S. the fact that the x86 is register poor is not a good thing. Having two few registers to manipulate data is often a hindrance. Saving 3 times as many registers doesn't take that long anyhow.

Substantiated claims? Ever heard of Jochen Liedtke and the L4 microkernel? He and many other researchers wrote the following papers if you'd care to read them:

The performance of microkernel based systems

Achieved IPC performance

Microkernels must and can be small

On Microkernel construction

Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces

If you'd like a breakdown, here it is: x86 sucks for context switch times for two main reasons, a)user/supervisor transition times are an order of magnitude slower than other architectures and b) a poorly designed TLB cache results in a flush whenever a context switch occurs(only if the address space changes of course). Any advantage the x86 architecture gains by having few registers is lost(and then some) by these other factors. This can be readily seen in operating systems and kernels that rely heavily on context switching such as microkernels.

For quick and dirty evidence: here. That's a link showing context switching times for Linux running on an 850 MHz PIII. The times typically hover around 12 microseconds. The papers I linked to above show achieved IPC times for L4 which are steady around 3 microseconds on much lower-end hardware. That's IPC, not just context switching, ie. context switch and copying data to another address space. The L4 teams have tweaked their implementation as fast as it can go on x86, and have achieved performance an order of magnitude higher than Linux(at least in this area). This demonstrates some pretty solid expertise. Given this, they say admit that x86 is very poor in this respect and a great hindrance in designing a good operating system. I believe some of the papers briefly discuss other architectures, but most of the focus is on the x86 platform because it's such a performance problem.

P.S. the fact that the x86 is register poor is not a good thing. Having two few registers to manipulate data is often a hindrance. Saving 3 times as many registers doesn't take that long anyhow.

Substantiated claims? Ever heard of Jochen Liedtke and the L4 microkernel? He and many other researchers wrote the following papers if you'd care to read them:

The performance of microkernel based systems

Achieved IPC performance

Microkernels must and can be small

On Microkernel construction

Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces

If you'd like a breakdown, here it is: x86 sucks for context switch times for two main reasons, a)user/supervisor transition times are an order of magnitude slower than other architectures and b) a poorly designed TLB cache results in a flush whenever a context switch occurs(only if the address space changes of course). Any advantage the x86 architecture gains by having few registers is lost(and then some) by these other factors. This can be readily seen in operating systems and kernels that rely heavily on context switching such as microkernels.

For quick and dirty evidence: here. That's a link showing context switching times for Linux running on an 850 MHz PIII. The times typically hover around 12 microseconds. The papers I linked to above show achieved IPC times for L4 which are steady around 3 microseconds on much lower-end hardware. That's IPC, not just context switching, ie. context switch and copying data to another address space. The L4 teams have tweaked their implementation as fast as it can go on x86, and have achieved performance an order of magnitude higher than Linux(at least in this area). This demonstrates some pretty solid expertise. Given this, they say admit that x86 is very poor in this respect and a great hindrance in designing a good operating system. I believe some of the papers briefly discuss other architectures, but most of the focus is on the x86 platform because it's such a performance problem.

P.S. the fact that the x86 is register poor is not a good thing. Having two few registers to manipulate data is often a hindrance. Saving 3 times as many registers doesn't take that long anyhow.

Also note that all the "better" microkernels (Neutrino, EROS, BeOS) are non-free. I think that's the basic reason that free software projects are not using them.

That's actually not true. L4 is GPL, and highly regarded. HURD will probably be ported to it soon, with a great performance increase.

• QNX: Everyone's heard of this one. They have a very good u-kernel.
• Opearting Systems Group at Dresden: They do alot of great work with u-kernels. They have code for L3 and L4, the first very promising, high-performance u-kernels(though they may not have designed them). They even have Linux running as a service on top of L4, so you may be able to run it right now! Also see This University and the L4KA page for other implementations of L4(ie. other architectures).
• Eros: EROS is a new operating system based on the architectures of earlier high-security capability systems(KeyKOS). Very promising and has performance comparable to L4. The measurements are in the papers section(usually towards the end of the paper). System is GPL'd.
• VSTa: a cool GPL'd hobby u-kernel system(in that it has no university or company backing). This one has a somewhat complete system, ie. self-hosted with gcc, vi, emacs, etc. Runs on a windows partition and uses GRUB to boot(all of which you'll need to run it). No performance metrics that I'm aware of.
• Fluke: No working system as far as I know. The kernel is complete and some performance measurements have been made. Looks promising and source is available(GPL I think).

As to why (so termed) 1st generation microkernels are still used as the base for newer systems, I can only speculate - but I believe that tradition is the main reason here (teaching an old dog new tricks tend to be hard). Just for the record, however, there is actually an effort to port it to L4.

For more info on L4 related issues, you could have a look at L4Ka, a C++ish implementation of the L4 API.

As to why (so termed) 1st generation microkernels are still used as the base for newer systems, I can only speculate - but I believe that tradition is the main reason here (teaching an old dog new tricks tend to be hard). Just for the record, however, there is actually an effort to port it to L4.

For more info on L4 related issues, you could have a look at L4Ka, a C++ish implementation of the L4 API.

The textbook that the University of Colorado has a good deal of information about the Mach microkernel (orginally derived from BSD), (although most implementations of Mach are somewhat old and/or abandoned). Mach had its hayday a few (like 8 or more) years ago (with Digital's OSF/1 and the NextSTEP system using the Mach2.5 implementation), but is currently pretty obsolete. The Hurd uses the GnuMach implementation (based on Mach3, i think), but is moving toward a better microkernel abstraction and to the L4 microkernel specifically.

There is a small OS that was build on top of the L4Ka implementation for a class project, called ChacmOS, and the authors graciously GPL'd the source. This is a wonderful source of information regarding the L4:
http://www.l4ka.org/projects/ChacmOS/

And a page dedicated to L4:
http://www.cse.unsw.edu.au/~disy/L4/

Plus there is work on doing it for PowerPC and also plans for upcoming 64 bit architectures like IA-64. A fairly new member of the L4 kernel family, the L4Ka kernel is actually quite portable. Doing ports to other architerures is as such not a big of a hurdle as it used to be.

Of course, in a real system you also have other tasks which needs to interact with the OS task. This occurs (almost) exclusively through IPC mechanisms, and IPC mechanisms have therefore been identified as the main performance bottleneck for microkernel systems. The IPC mechanism basically deals with transferring (usually a small) amount of words from one task/thread to another, and performing a context switch between the tasks/threads. There are three sides to the cost associated with this:

1. The added number of processor cycles used to actually perform the context switch.
2. The added number of flushed cache lines due to the microkernel design.
3. The added number of TLB invalidations/flushes.

Hehe. Showing a screenshot of,e.g., a Linux server running on top of L4 doesn't seem to impress to many people. That's one of the problems we usually have to face when we demonstrating what we do to non-insiders. And, by the way, the ``most official'' L4 site is now located on the L4Ka website.

As for the performance degradation that the -kernel architecture imposes on the system, there has been quite a lot of research in the last ten years indicating that this effect can be alleviated. Moreover, much of the performance degradation due to the added number of context switches in -kernel systems is due to inneficient/inapropriate hardware mechanisms and design. By harnessing state of the art hardware design (e.g., IA-64), we may come to see that the added overhead of context switches is ignorable. There is work underway to create efficient -kernels for these more arcane architectures, and only time will tell whether our hopes can be reached or not.

Also, -kernel technology is believed to pose a compelling soultion to the one-size-fits-all problem that you address in conjunction with Linux. To put it short, one would compile the operating system components so that they match the exact requirements that you meet in, e.g., pervasive computing or big irons. In fact, IBM is doing joint research with a number of universities aiming at providing a multiserver version of Linux - SawMill Linux - with these exact goals in mind. This work may of course fail (that's the beauty of research), but I think it is a bit early yet to put the last nail in the coffin for multiserver operating systems.

And just for the records: SawMill is hopefully going GPL any time soon now, enabling people to use it with the GPLed Fiasco or newly developed L4Ka -kernels. (That should probably make you GPL zealots happy. ;-)

As for the performance degradation that the -kernel architecture imposes on the system, there has been quite a lot of research in the last ten years indicating that this effect can be alleviated. Moreover, much of the performance degradation due to the added number of context switches in -kernel systems is due to inneficient/inapropriate hardware mechanisms and design. By harnessing state of the art hardware design (e.g., IA-64), we may come to see that the added overhead of context switches is ignorable. There is work underway to create efficient -kernels for these more arcane architectures, and only time will tell whether our hopes can be reached or not.

Also, -kernel technology is believed to pose a compelling soultion to the one-size-fits-all problem that you address in conjunction with Linux. To put it short, one would compile the operating system components so that they match the exact requirements that you meet in, e.g., pervasive computing or big irons. In fact, IBM is doing joint research with a number of universities aiming at providing a multiserver version of Linux - SawMill Linux - with these exact goals in mind. This work may of course fail (that's the beauty of research), but I think it is a bit early yet to put the last nail in the coffin for multiserver operating systems.

And just for the records: SawMill is hopefully going GPL any time soon now, enabling people to use it with the GPLed Fiasco or newly developed L4Ka -kernels. (That should probably make you GPL zealots happy. ;-)

Well, there is actually no such thing as L4KaLinux. There is L4Ka though, which is another implementation of the L4 -kernel, and which is able to host the L4Linux kernel (leaves you with one less code fork ;-).