OSNews

"Besides, it's not like we don't have massively powerful systems that can mask the latencies by sheer power alone."

Take this with a grain of salt, because I'm far from being an expert, but I think that an important part of the performance impact is due to architecture aspects; today's chips (well, x86 stuff at least) aren't really designed to run micro-kernels (context switches are expensive, no real support for messaging, etc.)

BTW, keep in mind context switches are nothing but waste of energy. Why not minimize them in the first place?

As I understand it, though I'm not an expert, x86 does provide hardware context switching but no mainstream operating systems use it because it doesn't save all the registers present (specifically floating point registers) and I think it isn't as fast as one might suspect.

Context switches are a huge waste of energy and recent schedulers are going a long way to try to minimise unnecessary ones while maintaining good interactivity. Work is also being put into ensuring threads don't wake up for no reason. I don't think that x86 makes this easy though. Maybe tasks are unnecessarily granulated into separate processes, particularly in (dare I say it) UNIX style operating systems.

Most operating systems are based around the ideas of a kernel, kernel modules, processes, threads, fibres, libraries. I think that there could possibly be more appropriate types of task than the ones outlined above, and I know research is being done into this sort of thing. Essentially, though, it generally comes down to interactivity vs throughput. If you have a lot of context switches (intelligent or not) you generally have better interactivity but worse throughput. The inverse is true.

Assuming hardware support for message queues and so on, I wonder if there's any work being done on a completely event based operating system where libraries and apps are implemented entirely as services. That would seem to match UI principles. I think hardware generally operates in an event driven mode, so the way that tasks are implemented as "processes" with context switches would seem to be an inappropriate abstraction.

Edited 2007-08-12 16:03

The situation is a lot more complex. First, context switches waste time in different actions (state saving and restoration, process management overhead, cache/tlb misses, etc.) that all have to be considered independently. This is further complicated by the fact that IPC mechanisms in a microkernel can be implemented in a lot of ways (for example, remote procedure calls can be implemented without thread switching, thus saving time).

Secondly, microkernels do not need to do context switching as often as usually claimed, *provided* that programmers get used to asynchronous system requests. If several system requests do not depend on each other's results, they can all be issues with only a single context switch (or at least, a number of context switches equal to the number of targeted service processes).

Third, one has to consider that even microkernels aren't the blue sky. While claimed to be much easier to use as a developer, microkernels produce nondeterministic behaviour between the different service processes. Stallman once talked in a speech about this problem and how it was one major issue with HURD. If there is any one argument that I could bring up against microkernels, then it's this one. It's not an unsolvable problem, but a really hard one. However, it assumes that the processes in a microkernel run concurrently, which is by no means set in stone (remember remote procedure call based IPC).

To sum it up, there is no such thing as "the" microkernel. Saying that microkernels are faster, slower, more secure, less secure, or whatever simply ignores that microkernels themselves are a huge range of possibilities, and much of that is still research area.