OS Structure and PerformanceReconsidering the Kernel InterfaceThe Microkernel PhilosophyA Fuzzy Look at Mach and NTMicrosoft NT ObjectsNT ProcessesMach OverviewMachEvaluating OS StructuresUser/Kernel Division of FunctionUnix/Mach System CallsWhat to KnowIssues and Questions for OS PerformanceArchitectural Basis of OS PerformanceOS Implications for ArchitecturePerformance-Driven OS DesignExamplesCosts of Process Creation by ForkAdditional Costs of Fork on Mach or NTExec RevisitedCosts of ExecExec on a MicrokernelLower Bounds on IPCOS Structure and PerformanceOS Structure and PerformanceReconsidering the Kernel InterfaceReconsidering the Kernel InterfaceMach and NT are representative of systems that seek to provide richer, more general kernel interfaces than Unix.•decouple elements of process abstractionvirtual address space, memory segments, threads, resources, interprocess communication (IPC) endpoints•provide a fully general set of kernel primitives for combining these essential elements in arbitrary wayspowerful enough to implement Unix “as an application program”the kernel interface is not the programming interface•rethink division of function between kernel and user spaceWhich features must be supported in the kernel?The Microkernel PhilosophyThe Microkernel PhilosophyThe microkernel philosophy evolved in the mid-1980s as a reaction to the increasing complexity of Unix kernels.•V system [Cheriton]: kernel is a “software backplane”advent of LAN networks: V supports distributed systems, and mirrors their structure internally (decomposed)•Mach: designed as a modern, portable, reconfigurable Uniximprove portability/reliability by “minimizing” kernel codesupport multiple “personalities”; isolate kernel from API changessupport multiprocessors via threads and extensible VM systemMicrokernels are widely viewed as having “failed” today, but some key ideas (and code) survive in modern systems.A Fuzzy Look at Mach and NTA Fuzzy Look at Mach and NT“microkernel”WindowssubsystemserverWindowsprocessUnixprocessUnixsubsystemserverNT “kernel” is the core ofthe “executive”.Environment server creates processesand operates on them via system calls;kernel may delegate process systemcalls to the environment server.Disclaimer: this is the concept behind Mach and the original NT, but early Mach 2.5 and today’s W2K/XP look quite different.Microsoft NT ObjectsMicrosoft NT ObjectsMost instances of NT kernel abstractions are “objects” named by protected handles held by processes.•Handles are obtained by create/open calls, subject to security policies that grant specific rights for each handle.•Any process with a handle for an object may operate on the object using operations (system calls).Specific operations are defined by the object’s type.portfileeventobjecthandlesuser space kernelNT object handles are named,represented, and protected exactlylike Unix file descriptors.NT ProcessesNT Processes1. A raw NT process is just a virtual address space, a handle table, and an (initially empty) list of threads.2. Processes are themselves objects named by handles, supporting specific operations.create threadsmap sections (VM regions)3. NtCreateProcess returns an object handle for the process.Creator may specify a separate (assignable) “parent” process.Inherit VAS from designated parent, or initialize as empty.Handles can be inherited; creator controls per-handle inheritance.Mach OverviewMach OverviewMach is more general than NT in that objects named by handles can be served by user-mode servers.•All handles are references to message queues called ports.•Given an appropriate handle (rights) for the port, a thread can send or receive from a port: it’s a capability.Mach has a rich and complex set of primitives for sending/receiving on ports and transferring port rights.•Some ports are served by the kernel.•Ports can be served by user processes (tasks).•Everything is a port; all interactions are through ports.•Communication (IPC) performance is everything.MachMachmicrokernelUnixprocessUnixservertasks/VMthreads/schedulingports/messagesemulatorreflectedsyscall trapIPCexceptionsEvaluating OS StructuresEvaluating OS StructuresHow do we evaluate OS structures and implementations?•Maintainability, extensibility, reliability, and elegance are difficult to quantify.•Systems research is a quantitative discipline.“Performance is paramount.” [Cheriton]How can we identify and separate the effects caused by:•artifacts of the current state of hardware technology?•characteristics of the workload?•essential properties of structure or implementation?How can we draw conclusions of long-term significance from measurements of any particular system?User/Kernel Division of FunctionUser/Kernel Division of Function1. Many system calls don’t require access to mutable global data in the system (e.g., the Unix server).•examples: getpid, installing signal handlersdata items are constants or are used only within the emulator2. The system can reduce the cost of these operations by executing them entirely within a library.e.g., the Mach emulator, Unix malloc and free3. A kernel or server primitive is needed only in cases involving resource allocation or protection.thread libraries, user-level IPC [T. Anderson et. al]logical conclusion: Exokernel “library operating systems”Unix/Mach System CallsUnix/Mach System CallsmicrokernelprocessUnix serveremulatorReflected syscall trap: redirect to emulator; send message to server.IPCSyscall trampoline offers binary compatibility at higher costthan a DLL (extra trap/return): either scheme can be used.Extra TLB referencesin server.Extra trap/return for syscall messaging to server.Some system calls are handled directly in the emulator.What to KnowWhat to Know1. The remaining slides in this batch serve to illustrate the effect of OS structures on performance. I did not cover them in class this year, but they may help to reinforce the discussions about OS structure and implementation.2. Be sure that you understand the key ideas behind the three alternative structures we looked at: microkernels, library OS (Exokernel), and extensible kernels (SPIN). Be able to compare/contrast the goals, approaches, strengths, and weaknesses of each.3. For the discussion of Exokernel and SPIN in class I referenced some of the high-level slides from Engler and Savage, which are available on the Engler and SPIN web sites linked through