Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Macro- vs. Micro- Kernels Matthew Fluet CS614 – Advanced Systems April 5, 2001 Macro-Kernel OSs Examples Traditional UNIX VMS OS is implemented in “one piece” Knowledge about the basic system structure is spread throughout the operating system Micro-Kernel OSs Examples Mach Chorus Amoeba OS is implemented in “separate pieces” Kernel controls the basic hardware resources Services implement the unique characteristics of an OS environment Mach Carnegie Mellon University: 1985 – 1994 Portions incorporated into a number of commercial OSs NeXT OS and Mac OS X DEC's OSF/1 for the DEC Alpha IBM's OS/2 for the RS6000 based machines Development continuing in University of Utah's Flexmach project and the Free Software Foundation's HURD system Mach – Goals Support for multiple threads of control within a single address space An extensible and secure interprocess communication facility Architecture independent virtual memory Integrated IPC/VM support Hooks for transparent shared libraries to provide binary compatibility with existing OS environments Mach – Abstractions Task: an execution environment in which threads may run Thread: a basic unit of CPU utilization Port: a communication channel that supports send and receive Message: a typed collection of data objects used in communication between threads Mach – Tasks and Threads Tasks are related by a tree structure of task creation operations Regions of virtual memory can be marked as inheritable read-write, copy-on-write, or none Parallelism can be achieved in three ways A single task with many threads executing in a shared address space Many tasks related by task creation that share restricted regions of memory Many tasks communicating via messages Mach – Virtual Memory Handle page faults and page-out data requests outside the kernel VM objects are represented as communication channels Kernel sends message to a pager task Flexibility allows efficient implementations File systems Databases Dynamic encryption and/or compression Network shared memory Mach – IPC Ports and messages are used to provide location independence, security, and data type tagging Ports can have any number of senders, but only one receiver Messages have fixed length headers and a variable sized collection of typed data objects Mach – Networking Kernel provides no mechanism for IPC over a network Network Servers: user-level tasks that allow transparent IPC over a network Network servers act as local representatives for tasks on remote nodes Mach – OS emulation Server tasks run on top of the kernel Multithreaded UNIX Server A monolithic kernel run as a user program Multiserver UNIX A collection of servers providing UNIX functionality Mach – Servers Examples Name Server Task Manager Authentication Server Network Server UNIX File Server NFS Server UNIX TTY Server UNIX Pipe Server Amoeba Vrije Universiteit and Centrum voor Wiskunde en Informatica: 1983 - 1996 Amoeba – Goals Distribution – connecting together many machines Parallelism – allowing individual jobs to use multiple CPUs easily Transparency – having the collection of computers act like a single node Performance – achieving all of the above in an efficient manner Amoeba – Objects An object is conceptually an abstract type Software and hardware objects Each object managed by a server process to which RPCs can be sent A capability is a 128-bit value Server Port Object # Rights Check Field 48 24 8 48 Amoeba – Remote Operations Primitives get_request(req_hdr, req_buf, req_size) put_reply(rep_hdr, rep_buf, rep_size) do_operation(req_hdr, req_buf, req_size, rep_hdr, rep_buf, rep_size) Return status Request delivered and executed Request not delivered or executed Status unknown Amoeba – Threads All threads in a process share the same address space Threads can (optionally) synchronize with mutexes and semaphores Threads are scheduled by the process Amoeba – Servers Examples Memory Server & Process Server Bullet Server Segment: a contiguous area of memory with a capability Process descriptor: a data structure that provides information about a stunned process Implements a file system Directory Server Provides a mapping of names (ASCII strings) to 128-bit capabilities for access to the file system Ameoba – WANs Domain: an inter-connected collection of local area networks Broadcasts limited to a single domain Processes publish services outside their domain by using the Service for Wide Area Networks (SWAN) Server and client agents coordinate between domains Amoeba – OS Emulation UNIX emulation Session server provided to handle state information and handle fork and exec Chorus INRIA: 1979 – 1986 Chorus systèmes: 1987 – 1991 Chorus – Goals High-level coupling of applications Gradual on-line evolution Straightforward underlying architecture which allows the modularity of the application to be mapped onto the operational system and which conceals unnecessary details of distribution from the application Chorus - Abstractions Nucleus: kernel that manages the exchange of messages between ports attached to actors Actor: an address space with components in both user and system space Threads: one or more in each actor Ports: global unique identifiers attached to an actor for exchange of messages by IPC Port Groups: provide multicast capabilities Chorus - Nucleus At the lowest level, manages the local physical resources of a site At the highest level, provides a location independent IPC mechanism Chorus – Actors Defines a protected address space, split into user address space and system address space System address space on a site is identical for all actors on a site Restricted access to system address space An actor is tied to one site and all threads of an actor are executed on that site A site failure leads to the complete crash of its actors Chorus – Ports and Messages Message: a contiguous byte string logically copied from sender’s address space to the receiver’s address space Ports: represents both an address and an ordered collection of unconsumed messages Attached to one actor at a time Can migrate from one actor to another Port groups Chorus – IPC and RPC IPC: asynchronous message sending Client is blocked only during local processing No guarantee that the message will be received RPC: synchronous remote procedure call Chorus – VM management Segment: the unit of exchange between VM system and data providers Global object with capabilities Managed by system actors called mappers Regions: division of an actor’s address space Contains a portion of a segment mapped to a given virtual memory address with specified access rights Chorus – Networking Kernel support for reconfiguration Port groups Port migration Network manager Remote IPC and RPC Locating distant ports Remote host failure handling Chorus - Subsystems Sets of actors that export a unified API UNIX subsystem Micro-Kernel OSs Mach Tasks/Actors Memory inheritance Amoeba Chorus Process migration Tied to a site Ports Capabilities Port groups; Port migration Virtual Memory Pagers Segments (no swapping or paging) Segments, mappers, regions Networking Kernel support; Limited kernel support Group comm. No kernel support Criticisms and Questions Is there a significant advantage in using a micro-kernel design if one only implements a UNIX emulation server? Is completely transparent remote IPC and RPC desirable? How about transparency of communication over a LAN vs. over a WAN? Philosophy - IPC Micro-kernel applications use crossaddress space IPC to interact with traditional OC services System call is faster than a crossaddress space IPC But, absolute difference has reached the point where it can largely be ignored Philosophy – IPC (cont.) IPC has gotten faster faster than the rest of the OS Performance is dominated by caches, not address spaces All data does not need to be marshaled through the kernel All services do not need a hardware firewall Implementation – Default MM Implementation of the default memory manager for Mach 3.0 that resides entirely in user space Handles all paging traffic to backing storage Uses a small set of kernel privileges to lock itself in memory and prevent deadlock Implementation – Default MM Requirements for the default memory manager The default memory manager must be resident All pages moving between the kernel and the default memory manager must remain resident It cannot block to wait for more physical memory It cannot block to wait for the file system to allocate temporary disk storage, since the file system itself may be pageable Implementation – Default MM Required extending the kernel interface with two system calls Lock a specified range of virtual addresses for the task into memory Permanently acquires a kernel stack for the thread Bypass the disk allocation problem by using a pre-specified list of disk blocks