On Microkernel Construction

This 1995 paper from GMD attempts to confront and debunk some of the myths
associated with microkernel design.  Specifically, popular consensus seems to
hold that microkernels are inherently inefficient and inflexible.  The author,
Jochen Liedtke, demonstrates that microkernels are neither inherently
inefficient nor inherently inflexible.  Instead, these faults arise from
attempts to inappropriately overload the kernel or from the incompetance of the
system implementers.  The paper presents a number of concepts needed for a
successful microkernel, including the need for inherent non-portability.

The paper is perhaps motivated by the seeming gap between the promise and
reality of microkernels.  The year is 1995, and operating systems researchers
have spent years pontificating on the virtues of microkernels.  Unfortunately,
no one is using them.  There is a famous, amusing thread that was circulated in
1992 between Andrew Tanenbaum and Linux Torvalds about the irrelavance of Linux,
as Linux was defying the clear superiority of microkernels in favour of the
monolithic kernel approach.  The question begged (and perhaps still wimpers for)
answering -- if microkernels are superior, why does no one use them?

In Liedtke's mind, no one is using microkernels because no one can build them
well (or, at least as well as he can).  This may be a good time to note that the
arrogance and self-assuredness of the author ranges from distracting to
infuriating, hurting the depth and convincingness of the paper.  This may be a
good time to remind the author that he is not Dijkstra.  In order to remedy the
performance predicament, he argues that the number of primitive operations
implemented in the microkernel should be small.  Specifically, microkernels need
to implement address space protection, I/O support, threads and processes,
interprocess communication, traps and interrupts, and some form of unique
identifiers.

By implementing the above basic support throughout the operating system,
traditionally kernel-level tasks can now be implemented in user-land, including
pagers, real-time scheduling support, device drivers, TLB and second-level cache
support, remote communication, and a UNIX server.  By stressing flexibility and
performance, most traditional operating system tasks can be moved from the
kernel into userland.

The paper then launches into what must be one of Liedtke's strengths --
hardcore, cycle-counting analysis of different kernel implementations, and use
of that information to justify the feasibility of (and superiority of his)
microkernel designs.  He addresses kernel-user mode switches and shows that
their performance can be improved by an order of magnitude given an appropriate
implementation.  Similarly, address-space switches can be implemented in less
than 50 cycles, a trivial amount of time on a 2 GHz processor.  Similarly,
contrary to the hundreds of microseconds required for RPC in Mach, Amoeba, and
Spin, L3 takes just 10 us for a complete RPC roundtrip.

In order to achieve the performance gains Liedtke talks about in these papers,
intense processor-specific optimization is required.  He argues that the
traditional and intuitive method for building a microkernel -- separating the
microkernel into both a hardware-dependent and hardware-independent layer -- is
fatally flawed.  Specifically, because of the size and speed requirements of the
microkernel, it must be as small and fast as possible.  It needs to be the
hardware-dependent layer of the operating system.  While this observation may
seem obvious, it also flies in the face of decades of operating systems design.
Operating systems have stressed portability and abstraction in an effort to
enforce consistency and correctness.  Liedtke is arguing that this is exactly
the wrong model for microkernels.  A microkernel should be as finally tuned as
possible (albeit with a consistent user-level interface), with almost all
portable code living in user-land.

His results are at the same time obvious and interesting.  Clearly making code
architecture-dependent will allow for better performance.  On the other hand,
the insight that microkernels should be designed with this in mind may have been
a consideration not given serious thought before this study.  The implications
of his study are worrisome -- if microkernels are only successful with
processor-specific implementations, is the increased performance worth the
portability cost.