1 / 149

Advanced Operating Systems

Advanced Operating Systems. Lecture 3: OS design. University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani. How to design an OS. Some general guides and experiences. References “The Computer for the 21st Century”, Mark Weiser

vinny
Télécharger la présentation

Advanced Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Advanced Operating Systems Lecture 3: OS design University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani Distributed Operating Systems

  2. How to design an OS • Some general guides and experiences. • References • “The Computer for the 21st Century”, Mark Weiser • “Exokernel: An Operating System Architecture for Application Level Resource Management”, Dawson R., Engler M, Frans Kaashoek, et al. • “On Micro-Kernel Constructions“, Distributed Operating Systems

  3. Outline • New applications/requirements • Organizing operating systems • Some microkernel examples • Object-oriented organizations • Spring • Organization for multiprocessors Distributed Operating Systems

  4. New vision • Two important problems: location and scale. • Ubiquitous computing: tiny kernels of functionality • Virtual Reality • Mobility • Intelligent devices • distributed computing" make networks appear like disks, memory, or other nonnetworked devices. Distributed Operating Systems

  5. Ubiquitous computing • Transparent computing is the ultimate goal • Computers should disappear into the background • Computation becomes part of the environment • Computing everywhere • Desktop, Laptop, Palmtop • Cars, Cell phones • Shoes, Clothing, Walls (paper / paint) • Connectivity everywhere • Broadband • Wireless • Mobile everywhere • Users move around • Disposable devices Distributed Operating Systems

  6. Ubiquitous Computing • Structure • Resource and service discovery critical • User location an issue • Interface discovery • Disconnected operation • Ad-hoc organization • Security • Small devices with limited power • Intermittent connectivity • Agents • Sensor Networks Distributed Operating Systems

  7. Grid Computing • Federated system • No single controlling authority • Scheduling • Processors, bandwidth and other resources • Policy is an important issue • Reliability, security, of who can use, and what one is willing to use. • Systems • Globus toolkit • Condor • Related but not grid – CORBA, DCOM, DCE • Applications • Distributed supercomputing Distributed Operating Systems

  8. Peer-to-Peer Computing • Locating Cooperative elements • Scalability • OS support • Security • Policies

  9. P2P File Sharing Issues • Naming • Data discovery • Availability • Security • Encryption • Fault tolerance • Conflict resolution • Replication Distributed Operating Systems

  10. Other Peer to Peer Technologies • Ad-hoc networking • Untrusted nodes used to relay messages • Multiple routes (distributed and replicated) • Extends range, reduces power, increases aggregate bandwidth. • Increases latency, management more difficult. • Sensor networks • An application of ad-hoc networking • Add processing/reduction in the network Distributed Operating Systems

  11. What is the big deal? • Performance • Border crossings are expensive • Change in locality • Copying between user and kernel buffers • Application requirements differ in terms of resource management Distributed Operating Systems

  12. Operating System Organization • What is the best way to design an operating system? • Put another way, what are the important software characteristics of an OS? • What should be in OS kernel or application or partitioning. • Is there a minimal set for kernel? Distributed Operating Systems

  13. Important OS Software Characteristics • Correctness and simplicity • Power and completeness • Performance • Extensibility and portability • Flexibility • Scalability • Suitability for distributed and parallel systems • Compatibility with existing systems • Security and fault tolerance Distributed Operating Systems

  14. Common OS Organizations • Monolithic • Virtual machine • Layered designs • Kernel designs • Microkernels • Object-Oriented • Note that individual OS components can be organized these ways • Trade off between generality and specialization

  15. What are we shooting for? • OS should be thin (like a microkernel) providing only mechanisms not embodying policies (i.e. management) • Fine grain access to system resources while avoiding border crossings as much as possible (like DOS) • Allow flexible extensions for management of resources (like a microkernel) without sacrificing safety (like a monolithic kernel) Distributed Operating Systems

  16. Monolithic OS Design • Build OS as single combined module • Hopefully using data abstraction, compartmentalized function, etc. • OS lives in its own, single address space • Examples • DOS • early Unix systems • most VFS file systems

  17. Pros/Cons of Monolithic OS Organization • Highly adaptable (at first . . .) • Little planning required • Potentially good performance • Hard to extend and change • Eventually becomes extremely complex • Eventually performance becomes poor • Highly prone to bugs

  18. Virtual Machine Organizations • A base operating system provides services in a very generic way • One or more other operating systems live on top of the base system • Using the services it provides • To offer different views of system to users • Examples - IBM’s VM/370, the Java interpreter

  19. Pros/Cons of Virtual Machine Organizations • Allows multiple OS personalities on a single machine • Good OS development environment • Can provide good portability of applications • Significant performance problems • Especially if more than 2 layers • Lacking in flexibility

  20. Old idea • VM 370 • Virtualization for binary support for legacy apps • Why resurgence today? • Companies want a share of everybody’s pie • IBM zSeries “mainframes” support virtualization for server consolidation • Enables billing and performance isolation while hosting several customers • Microsoft has announced virtualization plans to allow easy upgrades and hosting Linux! • You can see the dots connecting up • From extensibility (a la SPIN) to virtualization Distributed Operating Systems

  21. Possible virtualization approaches • Standard OS (such as Linux, Windows) • Meta services (such as grid) for users to install files and run processes • Administration, accountability, and performance isolation become hard • Retrofit performance isolation into OSs • Linux/RK, QLinux, SILK • Accounting resource usage correctly can be an issue unless done at the lowest level (e.g. Exokernel) • Xen approach • Multiplex physical resource at OS granularity Distributed Operating Systems

  22. Full virtualization • Virtual hardware identical to real one • Relies on hosted OS trapping to the VMM for privileged instructions • Pros: run unmodified OS binary on top • Cons: • supervisor instructions can fail silently in some hardware platforms (e.g. x86) • Solution in VMware: Dynamically rewrite portions of the hosted OS to insert traps • need for hosted OS to see real resources: real time, page coloring tricks for optimizing performance, etc… Distributed Operating Systems

  23. Xen principles • Support for unmodified application binaries • Support for multi-application OS • Complex server configuration within a single OS instance • Paravirtualization for strong resource isolation on uncooperative hardware (x86) • Paravirtualization to enable optimizing guest OS performance and correctness Distributed Operating Systems

  24. Xen: VM management • What would make VM virtualization easy • Software TLB • Tagged TLB =>no TLB flush on context switch X86 does not have either • Xen approach • Guest OS responsible for allocating and managing hardware PT • Xen top 64MB of every address space. Why? Distributed Operating Systems

  25. Layered OS Design • Design tiny innermost layer of software • Next layer out provides more functionality • Using services provided by inner layer • Continue adding layers until all functionality required has been provided • Examples • Multics • Fluke • layered file systems and comm. protocols

  26. Pros/Cons of Layered Organization • More structured and extensible • Easy model and development • Performance: Layer crossing can be expensive • In some cases, unnecessary layers, duplicated functionality.

  27. Kernel OS Designs • Similar to layers, but only two OS layers • Kernel OS services • Non-kernel OS services • Move certain functionality outside kernel • file systems, libraries • Unlike virtual machines, kernel doesn’t stand alone • Examples - Most modern Unix systems

  28. Pros/Cons of Kernel OS Organization • Many advantages of layering, without disadvantage of too many layers • Easier to demonstrate correctness • Not as general as layering • Offers no organizing principle for other parts of OS, user services • Kernels tend to grow to monoliths

  29. Object-Oriented OS Design • Design internals of OS as set of privileged objects, using OO methods • Sometimes extended into application space • Tends to lead to client/server style of computing • Examples • Mach (internally) • Spring (totally)

  30. Object-Oriented Organizations • Object-oriented organization is increasingly popular • Well suited to OS development, in some ways • OSes manage important data structures • OSes are modularizable • Strong interfaces are good in OSes Distributed Operating Systems

  31. Object-Orientation and Extensibility • One of the main advantages of object-oriented programming is extensibility • Operating systems increasingly need extensibility • So, again, object-oriented techniques are a good match for operating system design Distributed Operating Systems

  32. How object-oriented should an OS be? • Many OSes have been built with object-oriented techniques • E.g., Mach and Windows NT • But most of them leave object orientation at the microkernel boundary • No attempt to force object orientation on out-of-kernel modules Distributed Operating Systems

  33. Pros/Cons of Object Oriented OS Organization • Offers organizational model for entire system • Easily divides system into pieces • Good hooks for security • Can be a limiting model • Must watch for performance problems Not widely used yet

  34. Microkernel OS Design • Like kernels, only less number of abstractions exported (threads, address space, communication channel) • Try to include only small set of required services in the microkernel • Moves even more out of innermost OS part • Like parts of VM, IPC, paging, etc. • System services (e.g. VM manager) implemented as servers on top • High comm overhead between services implemented at user level and microkernel limits extensibility in practice • Examples - Mach, Amoeba, Plan 9, Windows NT, Chorus, Spring, etc.

  35. Pros/Cons of Microkernel Organization • Those of kernels, plus: • Minimizes code for most important OS services • Offers model for entire system • Microkernels tend to grow into kernels • Requires very careful initial design choices • Serious danger of bad performance

  36. Organizing the Total System • In microkernel organizations, much of the OS is outside the microkernel • But that doesn’t answer the question of how the system as a whole gets organized • How do you fit together the components to build an integrated system? While maintaining all the advantages of the microkernel Distributed Operating Systems

  37. Some Important Microkernel Designs Micro-ness is in the eye of the beholder • Mach • Spring • Amoeba • Plan 9 • Windows NT

  38. Mach • Mach didn’t start life as a microkernel • Became one in Mach 3.0 • Object-oriented internally • Doesn’t force OO at higher levels • Microkernel focus is on communications facilities • Much concern with parallel/distributed systems

  39. Mach Model User processes User space Software emulation layer 4.3BSD emul. SysV emul. HP/UX emul. other emul. Kernel space Microkernel

  40. What’s In the Mach Microkernel? • Tasks & Threads • Ports and Port Sets • Messages • Memory Objects • Device Support • Multiprocessor/Distributed Support

  41. Mach Tasks • An execution environment providing basic unit of resource allocation • Contains • Virtual address space • Port set • One or more threads

  42. Mach Task Model Address space Process User space Thread Process port Bootstrap port Exception port Registered ports Kernel

  43. Mach Threads • Basic unit of Mach execution • Runs in context of one task • All threads in one task share its resources • Unix process similar to Mach task with single thread

  44. Task and Thread Scheduling • Very flexible • Controllable by kernel or user-level programs • Threads of single task can execute in parallel • On single processor • Multiple processors • User-level scheduling can extend to multiprocessor scheduling

  45. Mach Ports • Basic Mach object reference mechanism • Kernel-protected communication channel • Tasks communicate by sending messages to ports • Threads in receiving tasks pull messages off a queue • Ports are location independent • Port queues protected by kernel; bounded

  46. Port Rights • mechanism by which tasks control who may talk to their ports • Kernel prevents messages being set to a port unless the sender has its port rights • Port rights also control which single task receives on a port Distributed Operating Systems

  47. Port Sets • A group of ports sharing a common message queue • A thread can receive messages from a port set • Thus servicing multiple ports • Messages are tagged with the actual port • A port can be a member of at most one port set Distributed Operating Systems

  48. Mach Messages • Typed collection of data objects • Unlimited size • Sent to particular port • May contain actual data or pointer to data • Port rights may be passed in a message • Kernel inspects messages for particular data types (like port rights)

  49. Mach Memory Objects • A source of memory accessible by tasks • May be managed by user-mode external memory manager • a file managed by a file server • Accessed by messages through a port • Kernel manages physical memory as cache of contents of memory objects

  50. Mach Device Support • Devices represented by ports • Messages control the device and its data transfer • Actual device driver outside the kernel in an external object

More Related