sign in sign up
<<
Home , Address space, Microkernel

Historical Context

• Kernel – The mandatory part of an OS – Can use all features of a processor • Most early OS were monolithic – Complete OS was packed into a single kernel (, , ,…) • Problem: Kernels grew and became bloated (lots of code to maintain) • Approach: – Minimize kernel, implementing traditional operating services as trusted servers on top at user level. Request services via protected IPC requests.

User User file memory User pager . . . process process server server server space

Kernel microkernel space

1 Courtesy: Fabián E. Bustamante Maria Hybinette, UGA Maria Hybinette, UGA

Micro Kernels Monolithic vs MicroKernel

• Minimal Functionality • Trusted Servers as user processes on top • Advantages: – Maintainability (less code) – Flexibility – Modularity – Servers on top isolates malfunction and does not break kernel (even device drivers on top) • Disadvantage: Performance ?

User User file memory process User pager . . . process process server server server space

Kernel microkernel space

Courtesy: Wikpedia Maria Hybinette, UGA Maria Hybinette, UGA

Early Microkernels

• Slow – due to “cross-domain” information • Liedtke argues ’s overhead is due to poor transfers? (e.g., a version of the Mach Kernel implementation. • Optimized IPC implementation in his L3 MicroKernel at CMU). – Architectural level • Server-to-OS, OS-to-server IPC is thought to • System Calls, Messages, Direct Transfer, Strict Process Orientation, Control Blocks. be a major source of inefficiency – Algorithmic level • Identifier, Virtual Queues, Timeouts/Wakeups, Lazy • Much faster to communicate between two Scheduling, Direct Process Switch, Short Messages. modules that are both in OS – Interface level • Unnecessary Copies, Parameter passing. – Coding level • Misses, TLB Misses, Segment Registers, General Registers, Jumps and Checks, Process Switch. Maria Hybinette, UGA Maria Hybinette, UGA Liedtke’s L3 Kernel Address Spaces

• “A concept is tolerated inside the microkernel • The microkernel should hide the hardware only if moving it outside the kernel would aspect of address spaces or implementing prevent the implementation of the system's protection will be impossible. required functionality” • The 3 functions required by the microkernel – Address spaces are grant, map, and flush. – Threads and IPC • I/O rights and device drivers should be – Unique ids controlled by memory managers on top of the microkernel.

Maria Hybinette, UGA Maria Hybinette, UGA

Threads and IPC Unique Identifiers

• A thread is an activity executing inside an • Required for reliable and efficient local communication • The association of threads to address spaces • In theory cryptography could be used requires that threads be in the kernel • Too expensive in practice – Since threads are in the kernel, inter- • User programs could transfer control to process communication (IPC) must also be untrusted subsystems without the knowledge supported by the kernel of the receiving program

Maria Hybinette, UGA Maria Hybinette, UGA

Flexibility Switching Overhead

• With the concepts previously mentioned, the following • Kernel-user switches - microkernels (when constructed applications that are generally within the kernel need not properly) can improve kernels by 6 to 10 times be implemented in the microkernel: – Memory manager • Address space switches - properly constructed address – Pager space switches are not expensive and expensive – Multimedia resource allocation switching in other microkernels is due to – implementation, not problems with the concept – Second level cache and TLB • Thread switches and IPC - all existing microkernels are – Remote communication – server already 2 times faster than kernels, but 40 to 80 times • Conclusion - the only things that cannot be implemented faster RPC () is achievable on top of the given abstractions are the processor architecture, registers, first-level caches and first-level TLBs.

Maria Hybinette, UGA Maria Hybinette, UGA Memory Effects Non Portability

• The Mach microkernel has notably worse • Making a microkernel portable prevents them from memory system degradation than other achieving the necessary performance and flexibility • Cannot take advantage of specific hardware. kernels • Cannot take precautions to avoid performance • Degradation led to bad overall system problems with specific hardware. performance in Mach testing • The additional layer costs performance. • The authors show that properly constructed • Processors differ in instruction sets, register architecture, exception handling, etc., and there is no microkernels can avoid the memory general method that is efficient for all cases. Therefore degradation noted in Mach each new processor requires a new microkernel design

Maria Hybinette, UGA Maria Hybinette, UGA

Conclusion (1) Conclusion (2)

• Choosing the right abstractions that give the • Microprocessors are inherently not portable microkernel flexibility and good performance is • The most frequent microprocessor mistakes key (besides inappropriate abstractions) come from a • Existing (e.g., Mach ) slow microkernels choose lack of understanding of the combined hardware- inappropriate abstractions (too many, too specialized, inflexible) system or inefficient implementation • The presented mechanisms (address space with • “The presented design shows that it is possible to map, flush and grant operations, threads with IPC achieve well performing microkernels through and unique identifiers) form a minimal set of processor-specific implementations of processor- operations that is flexible enough for an arbitrary independent abstractions.”

Maria Hybinette, UGA Maria Hybinette, UGA

Resources

• http://www-cs- students.stanford.edu/~dbfaria/quals/summar ies/Liedtke-1995.txt • http://en.wikipedia.org/wiki/Microkernel • http://os.ibds.kit.edu/downloads/publ_1995_l iedtke_ukernel-construction.pdf • http://en.wikipedia.org/wiki/Jochen_Liedtke • https://en.wikipedia.org/wiki/Mach_(kernel)

Maria Hybinette, UGA