16th ACM Symposium on Operating Systems Principles (SOSP ’97), October 5–8, 1997, Saint-Malo, France
The Performance of µ-Kernel-Based Systems
Hermann H¨artig Michael Hohmuth Jochen Liedtke Sebastian Sch¨onberg Jean Wolter
Dresden University of Technology IBM T. J. Watson Research Center Department of Computer Science 30 Saw Mill River Road D-01062 Dresden, Germany Hawthorne, NY 10532, USA email: l4-linux@os.inf.tu-dresden.de email: [email protected]
based on pure µ-kernels, i. e. kernels that provide only ad- dress spaces, threads and IPC, or an equivalent set of primi- tives. This trend is due primarily to the poor performance ex- Abstract hibited by such systems constructed in the 1980’s and early 1990’s. This reputation has not changed even with the advent First-generation µ-kernels have a reputation for being too of faster µ-kernels; perhaps because these µ-kernel have for slow and lacking sufficient flexibility. To determine whether the most part only been evaluated using microbenchmarks. L4, a lean second-generation µ-kernel, has overcome these limitations, we have repeated several earlier experiments and Many people in the OS research community have adopted conducted some novel ones. Moreover, we ported the Linux the hypothesis that the layer of abstraction provided by pure operating system to run on top of the L4 µ-kernel and com- µ-kernels is either too low or too high. The “too low” fac- pared the resulting system with both Linux running native, tion concentrated on the extensible-kernel idea. Mechanisms and MkLinux, a Linux version that executes on top of a first- were introduced to add functionality to kernels and their ad- generation Mach-derived µ-kernel. dress spaces, either pragmatically (co-location in Chorus or Mach) or systematically. Various means were invented to For L4Linux, the AIM benchmarks report a maximum protect kernels from misbehaving extensions, ranging from throughput which is only 5% lower than that of native Linux. the use of safe languages [5] to expensive transaction-like The corresponding penalty is 5 times higher for a co-located schemes [34]. The “too high” faction started building kernels in-kernel version of MkLinux, and 7 times higher for a user- resembling a hardware architecture at their interface [12]. level version of MkLinux. These numbers demonstrate both Software abstractions have to be built on top of that. It is that it is possible to implement a high-performance conven- claimed that µ-kernels can be fast on a given architecture but tional operating system personality above a µ-kernel, and cannot be moved to other architectures without losing much that the performance of the µ-kernel is crucial to achieve this. of their efficiency [19]. Further experiments illustrate that the resulting system is In contrast, we investigate the pure µ-kernel approach by highly extensible and that the extensions perform well. Even systematically repeating earlier experiments and conducting real-time memory management including second-level cache some novel experiments using L4, a second-generation µ- allocation can be implemented at user-level, coexisting with kernel. (Most first-generation µ-kernels like Chorus [32] L4Linux. and Mach [13] evolved from earlier monolithic kernel ap- proaches; second-generation µ-kernels like QNX [16] and L4 more rigorously aim at minimality and are designed from 1 Introduction scratch [24].) The goal of this work is to show that µ-kernel based sys- The operating systems research community has almost com- tems are usable in practice with good performance. L4 is a pletely abandoned research on system architectures that are lean kernel featuring fast message-based synchronous IPC, This research was supported in part by the Deutsche Forschungsgemein- a simple-to-use external paging mechanism and a security schaft (DFG) through the Sonderforschungsbereich 358. mechanism based on secure domains. The kernel imple-
Copyright c 1997 by the Association for Computing Machinery, Inc. ments only a minimal set of abstractions upon which oper- Permission to make digital or hard copies of part or all of this work for ating systems can be built [22]. The following experiments personal or classroom use is granted without fee provided that copies are not were performed: made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with A monolithic Unix kernel, Linux, was adapted to run credit is permitted. To copy otherwise, to republish, to post on servers or to as a user-level single server on top of L4. This makes redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or L4 usable in practice, and gives us some evidence (at
[email protected]. least an upper bound) on the penalty of using a standard OS personality on top of a fast µ-kernel. The perfor- Unix-compatible operating system on top of a small kernel. mance of the resulting system is compared to the native We concentrate on the problem of porting an existing mono- Linux implementation and MkLinux, a port of Linux to lithic operating system to a µ-kernel. a Mach 3.0 derived µ-kernel [10]. A large bunch of evaluation work exists which addresses Furthermore, comparing L4Linux and MkLinux gives how certain application or system functionality, e. g. a pro- us some insight in how the µ-kernel efficiency influ- tocol implementation, can be accelerated using system spe- ences the overall system performance. cialization [31], extensible kernels [5, 12, 34], layered path organisation [30], etc. Two alternatives to the pure µ-kernel
The objective of three further experiments was to approach, grafting and the Exokernel idea, are discussed in show the extensibility of the system and to evaluate more detail in Section 7. the achievable performance. Firstly, pipe-based local Most of the performance evaluation results published else- communication was implemented directly on the µ- where deal with parts of the Unix functionality. An analy- kernel and compared to the native Linux implementa- sis of two complete Unix-like OS implementations regard- tion. Secondly, some mapping-related OS extensions ing memory-architecture-based influences, is described in (also presented in the recent literature on extensible ker- [8]. Currently, we do not know of any other full Unix nels) have been implemented as user-level tasks on L4. implementation on a second-generation µ-kernel. And we Thirdly, the first part of a user-level real-time memory know of no other recent end-to-end performance evaluation management system was implemented. Coexisting with of µ-kernel-based OS personalities. We found no substantia- 4 L Linux, the system controls second-level cache alloca- tion for the “common knowledge” that early Mach 3.0-based tion to improve the worst-case performance of real-time Unix single-server implementations achieved a performance applications. penalty of only 10% compared to bare Unix on the same hardware. For newer hardware, [9] reports penalties of about
To check whether the L4 abstractions are reasonably in- dependent of the Pentium platform L4 was originally 50%. designed for, the µ-kernel was reimplemented from scratch on an Alpha 21164, preserving the original L4 interface. 3 L4 Essentials Starting from the IPC implementation in L4/Alpha, we The L4 µ-kernel [22] is based on two basic concepts, threads also implemented a lower-level communication prim- and address spaces. A thread is an activity executing inside itive, similar to Exokernel’s protected control trans- an address space. Cross-address-space communication, also fer [12], to find out whether and to what extent the L4 called inter-process communication (IPC), is one of the most IPC abstraction can be outperformed by a lower-level fundamental µ-kernel mechanisms. Other forms of commu- primitive. nication, such as remote procedure call (RPC) and controlled After a short overview of L4 in Section 3, Section 4 ex- thread migration between address spaces, can be constructed plains the design and implementation of our Linux server. from the IPC primitive. Section 5 then presents and analyzes the system’s perfor- A basic idea of L4 is to support recursive construction mance for pure Linux applications, based on microbench- of address spaces by user-level servers outside the kernel. The initial address space σ essentially represents the phys- marks as well as macrobenchmarks. Section 6 shows the 0 extensibility advantages of implementing Linux above a µ- ical memory. Further address spaces can be constructed by granting, mapping and unmapping flexpages, logical pages kernel. In particular, we show (1) how performance can be n improved by implementing some Unix services and variants of size 2 , ranging from one physical page up to a complete of them directly above the L4 µ-kernel, (2) how additional address space. The owner of an address space can grant or services can be provided efficiently to the application, and map any of its pages to another address space, provided the (3) how whole new classes of applications (e. g. real time) recipient agrees. Afterwards, the page can be accessed in can be supported concurrently with general-purpose Unix both address spaces. The owner can also unmap any of its applications. Finally, Section 7 discusses alternative basic pages from all other address spaces that received the page concepts from a performance point of view. directly or indirectly from the unmapper. The three basic operations are secure since they work on virtual pages, not on physical page frames. So the invoker can only map and 2 Related Work unmap pages that have already been mapped into its own ad- dress space. Most of this paper repeats experiments described by Bershad All address spaces are thus constructed and maintained by et al. [5], des Places, Stephen & Reynolds [10], and En- user-level servers, also called pagers; only the grant, map gler, Kaashoek & O’Toole [12] to explore the influence of and unmap operations are implemented inside the kernel. a second-generation µ-kernel on user-level application per- Whenever a page fault occurs, the µ-kernel propagates it formance. Kaashoek et al. describe in [18] how to build a via IPC to the pager currently associated with the faulting
2 thread. The threads can dynamically associate individual in PALcode. Longer, interruptible operations enter PAL- pagers with themselves. This operation specifies to which code, switch to kernel mode and leave PALcode to perform user-level pager the µ-kernel should send the page-fault IPC. the remainder of the operation using standard machine in- The semantics of a page fault is completely defined by the structions. A comparison of IPC performance of the three interaction of user thread and pager. Since the bottom-level L4 µ-kernels can be found in [25]. pagers in the resulting address-space hierarchy are in fact main-memory managers, this scheme enables a variety of memory-management policies to be implemented on top of 4 Linux on Top of L4 the µ-kernel. I/O ports are treated as parts of address spaces so that they Many classical systems emulate Unix on top of a µ-kernel. can be mapped and unmapped in the same manner as mem- For example, monolithic Unix kernels were ported to Mach ory pages. Hardware interrupts are handled as IPC. The µ- [13, 15] and Chorus [4]. Very recently, a single-server ex- kernel transforms an incoming interrupt into a message to periment was repeated with Linux and newer, optimized ver- the associated thread. This is the basis for implementing all sions of Mach [10]. device drivers as user-level servers outside the kernel. To add a standard OS personality to L4, we decided to In contrast to interrupts, exceptions and traps are syn- port Linux. Linux is stable, performs well, and is on the way chronous to the raising thread. The kernel simply mirrors to becoming a de-facto standard in the freeware world. Our them to the user level. On the Pentium processor, L4 mul- goal was a 100%-Linux-compatible system that could offer tiplexes the processor’s exception handling mechanism per all the features and flexibility of the underlying µ-kernel. thread: an exception pushes instruction pointer and flags on To keep the porting effort low, we decided to forego any the thread’s user-level stack and invokes the thread’s (user- structural changes to the Linux kernel. In particular, we felt level) exception or trap handler. that it was beyond our means to tune Linux to our µ-kernel A Pentium-specific feature of L4 is the small-address- in the way the Mach team tuned their single-server Unix to space optimization. Whenever the currently-used portion the features of Mach. As a result, the performance measure- of an address space is “small”, 4 MB up to 512 MB, this ments shown can be considered a baseline comparison level logical space can be physically shared through all page ta- for the performance that can be achieved with more signifi- bles and protected by Pentium’s segment mechanism. As cant optimizations. A positive implication of this design de- described in [22], this simulates a tagged TLB for context cision is that new versions of Linux can be easily adapted to switching to and from small address spaces. Since the vir- our system. tual address space is limited, the total size of all small spaces is also limited to 512 MB by default. The described mech- 4.1 Linux Essentials anism is solely used for optimization and does not change the functionality of the system. As soon as a thread accesses Although originally developed for x86 processors, the Linux data outside its current small space, the kernel automatically kernel has been ported to several other architectures, includ- switches it back to the normal 3 GB space model. Within a ing Alpha, M68k and SPARC [27]. Recent versions con- single task, some threads might use the normal large space tain a relatively well-defined interface between architecture- while others operate on the corresponding small space. dependent and independent parts of the kernel [17]. All in- terfaces described in this paper correspond to Linux version 2.0. Pentium — Alpha — MIPS Linux’ architecture-independent part includes process and Originally developed for the 486 and Pentium architecture, resource management, file systems, networking subsystems experimental L4 implementations now exist for Digital’s Al- and all device drivers. Altogether, these are about 98% of the pha 21164 [33] and MIPS R4600 [14]. Both new implemen- Linux/x86 source distribution of kernel and device drivers. tations were designed from scratch. L4/Pentium, L4/Alpha Although the device drivers belong to the architecture- and L4/MIPS are different µ-kernels with the same logical independent part, many of them are of course hardware de- API. However, the µ-kernel-internal algorithms and the bi- pendent. Nevertheless, provided the hardware is similar nary API (use of registers, word and address size, encoding enough, they can be used in different Linux adaptions. of the kernel call) are processor dependent and optimized Except perhaps exchanging the device drivers, porting for each processor. Compiler and libraries hide the binary Linux to a new platform should only entail changes to the API differences from the user. The most relevant user-visible architecture-dependent part of the system. This part com- difference probably is that the Pentium µ-kernel runs in 32- pletely encapsulates the underlying hardware architecture. bit mode whereas the other two are 64-bit-mode kernels and It provides support for interrupt-service routines, low-level therefore support larger address spaces. device driver support (e. g., for DMA), and methods for in- The L4/Alpha implementation is based on a complete re- teraction with user processes. It also implements switching placement of Digital’s original PALcode [11]. Short, time- between Linux kernel contexts, copyin/copyout for transfer- critical operations are hand-tuned and completely performed ring data between kernel and user address spaces, signal-
3 user process ing, mapping/unmapping mechanisms for constructing ad- user process
dress spaces, and the Linux system-call mechanism. From