On Microkernel Construction Preliminaries Review THE Strict hierarchical structure Sequential processes Synchrnoization (semaphors) Virtual addressing Pearls of wisdom UNIX Minimal mechanism (everything is a file) Lessons Outline History Microkernel: Goals Performance History late 60's, early 70's: Unix, THE -- elegant, minimal systems -- Unix: constrained by limited HW -- THE: constrained by ``fear'' -- Both: pretty good designers... 70's, 80's: systems grow mid 80's-90's (and continuing in some pockets): microkernel -- reaction to ``bloat'' of monolithic kernels -- find ``scientific'' basis for ``minimal system'' -- what needs to be in an OS? -- Unix/THE -- answered via taste of designers -- microkernels -- attempt to answer more systematically/scientifically This paper's motivation: Controversy: are performance problems with ì-kernels are due to The u-kernel approach. The concepts implemented by a particular u-kernel. The The u-kernel implementation. NOTE: Inter-process communication (IPC) holds the keys to the kingdom for micro-kernels. They implement functionality in user address spaces, so switching address spaces better be fast. Microkernel: approach, advantages (see slides from dresden-1-notes.pdf) Advantages: -- more flexible: easier to add/change functionality since most is out of kernel -- Can anyone change the file system? No. Still need root permission. Still need dedicated partition. ... -- Is development cycle faster? Maybe. Don't need to recompile whole kernel, but (often) still need to reboot. May have better debugging tools for user level process than kernel. -- Today: Loadable modules + modular design gain most of microkernel advantages in monolithic kernel -- more reliable: crash of one module doesn't bring down whole kernel -- Maybe...if your file system hangs, you still probably need a reboot... QUESTION: are these compelling? Microkernel: Architecture/fundamental requirements fundamental requirements: protection: Subsystem S cannot be read or modified by subsystem S' authenticated communication: Sybsystem S1 and S2 establish a communication channel that cannot be corrupted or eavesdropped by S' Address space Grant: owner can grant any of its pages to another space (postcondition: grantor no longer can access page; grantee can Map: owner can map any of its pages to another space (postcondition: both can access) Flush: owner can revoke access of any its pages from other address spaces ``'thse primitives leave memory mangement and paging outside the microkernel; only these three operations are in the kernel; implement memory managers and pagers ove rthat.]'' example: start main mem allocator start file server main allocator: grant disk device controller to file server main allocator: grant working pages as needed application request to map file into memory send IPC to file server fs: read page from disk, map to app replace page: fs: flush from app + self... IPC/Threads reliable, authenticated, private send from one AS to another why discuss IPC with threads? Why are threads ``fundamental'' and concept included in kernel? They say: The dynamic or static association to address spaces is the decisive reason for including the thread concept (or something equivalent) in the ì-kernel. What does this mean? I say: [event-driven: receive message triggers scheduling of a thread] IO -- use above abstractions map IO pages to user-level servers map interrups to IPC messages Performance -- the challenge -- Performance Windows NT originally a microkernel...performance so bad they brought much back into the kernel Architecture system call monolithic: 2 kernel entry/exits microkernel: 4 kernel entries/exits + 2 context switches Application --> driver + kernel <-- Application --> kernel driver <-- --> Application <-- call between system services monolithic: 0 kernel entries/exits (1 function call) microkernel: 4 kernel entries/exits + 2 context switches NOTE: Inter-process communication (IPC) holds the keys to the kingdom for micro-kernels. They implement functionality in user address spaces, so switching address spaces better be fast. Measurements Kernel call: Mach Microkernel: 900 cycles (18us) on 50MHz 486 107 cycles: fundamental hardware costs 800 cycles: kernel overheads (instructions, TLB misses, ...) L3: 123-180 cycles 15-72 cycles: kernel overhead Addres space switch: Main cost: TLB flush (on most architectures) 486 worst case: 96*9 = 864 cycles Trick (Pentium, powerPC): use segment registers to emulate address-space-tagged TLB (trick: as long as AS1 and AS2 use different segment #'s and different ranges of virtual addresses, then there can be no conflicts in TLB so no need to reload) --> 39 cycles on 486 and 15 cycles on Pentium Full IPC (address space + thread switch): (adds saving/restoring registers to plain address space switch) L3: 250 cycles Memory pressure: application + microkernel + server v. application + kernel service --> make ``microkernel'' part small; avoid copying data On Microkernel Construction (1) Performance overheads smaller than believed/not fundamental (2) Implementation must exploit HW details to minimize costs QUESTION: (1) Are you convinced that microkernels can be as efficient as monolithic kernels? (Are you convinced that ``mach is slow'' does not generalize to ``microkernels are slow''?) (2) How big a disadvantage is lack of portability? ``half changed'' when porting from 486 to pentium...sounds bad, right? (how does changing 50\% of LOC to port 30K-line L4 compare to HAL in linux or Solaris?) (3) How fundamental are claimed advantages of microkernel approach?