Advanced Operating Systems

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

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

3. Outline • New applications/requirements • Organizing operating systems • Some microkernel examples • Object-oriented organizations • Spring • Organization for multiprocessors Advanced 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. Advanced Operating Systems

5. 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 Advanced Operating Systems

6. 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? Advanced Operating Systems

7. 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 Advanced Operating Systems

8. Common OS Organizations • Monolithic • Virtual machine • Structured design • Layered designs • Object-Oriented • Microkernels • Trade off between generality and specialization Advanced Operating Systems

9. Monolithic OS Design • Build OS as single combined module • Hopefully using data abstraction. • OS lives in its own, single address space • Examples • DOS • early Unix systems • most VFS file systems Advanced Operating Systems

10. 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 Advanced Operating Systems

11. 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 Advanced Operating Systems

12. 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 • Lacking in flexibility Advanced Operating Systems

13. 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! Advanced Operating Systems

14. 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 Advanced Operating Systems

15. 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. Advanced Operating Systems

16. Two layer OS Designs • Only two OS layers • Kernel OS services • Non-kernel OS services • Move certain functionality outside kernel • file systems, libraries • Examples - Most modern Unix systems Advanced Operating Systems

17. Pros/Cons of two layer OS • 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 Advanced Operating Systems

18. 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) Advanced Operating Systems

19. 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 • Very good extensible. Advanced Operating Systems

20. 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 Advanced Operating Systems

21. 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 Advanced Operating Systems

22. 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. Advanced Operating Systems

23. 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 Advanced Operating Systems

24. 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 Advanced Operating Systems

25. Some Important Microkernel Designs Micro-ness is in the eye of the beholder • Spin • X-kernel • Exokernel • Mach • Spring • Amoeba • Plan 9 • Windows NT Advanced Operating Systems

26. 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 Advanced Operating Systems

27. Mach Model User processes User space Software emulation layer 4.3BSD emul. SysV emul. HP/UX emul. other emul. Kernel space Microkernel Advanced Operating Systems

28. Mach Microkernel? • Tasks & Threads • Ports and Port Sets • Messages • Memory Objects • Device Support • Multiprocessor/Distributed Support Advanced Operating Systems

29. Mach Task Model Address space Process User space Thread Process port Bootstrap port Exception port Registered ports Kernel Advanced Operating Systems

30. 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 Advanced Operating Systems

31. System Port • System controls who may talk to a port by setting port rights, who can receive message, who can sent message, etc. • Port can make a port group or port set • Messages are Sent to particular port(s) • Devices represented by ports Advanced Operating Systems

32. Mach Messages • Typed collection of data objects • Unlimited size • 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) Advanced Operating Systems

33. 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 Advanced Operating Systems

34. Mach Multiprocessor and DS Support • Messages and ports can extend across processor/machine boundaries • Location transparent entities • Kernel manages distributed hardware • Per-processor data structures, but also structures shared across the processors • Intermachine messages handled by a server that knows about network details Advanced Operating Systems

35. Mach’s NetMsgServer • User-level capability-based networking daemon • Handles naming and transport for messages • Provides world-wide name service for ports • Messages sent to off-node ports go through this server Advanced Operating Systems

36. NetMsgServer in Action User space User space User process User process NetMsgServer NetMsgServer Kernel space Kernel space Receiver Sender Advanced Operating Systems

37. Mach and User Interfaces • Mach was built for the UNIX community • UNIX programs don’t know about ports, messages, threads, and tasks • How do UNIX programs run under Mach? • Mach typically runs a user-level server that offers UNIX emulation • Either provides UNIX system call semantics internally or translates it to Mach primitives Advanced Operating Systems

38. Windows NT • More layered than some microkernel designs • NT Microkernel provides base services • Executive builds on base services via modules to provide user-level services • User-level services used by • privileged subsystems (parts of OS) • true user programs Advanced Operating Systems

39. Windows NT Diagram User Processes Protected Subsystems User Mode Win32 POSIX Kernel Mode Executive Microkernel Hardware Advanced Operating Systems

40. NT Microkernel • Thread scheduling • Process switching • Exception and interrupt handling • Multiprocessor synchronization • Only NT part not preemptible or pageable • All other NT components runs in threads Advanced Operating Systems

41. NT Executive • Higher level services than microkernel • Runs in kernel mode • but separate from the microkernel itself • ease of change and expansion • Built of independent modules • all preemptible and pageable Advanced Operating Systems

42. NT Executive Modules • Object manager • Security reference monitor • Process manager • Local procedure call facility (a la RPC) • Virtual memory manager • I/O manager Advanced Operating Systems

43. Typical Activity in NT Win32 Protected Subsystem Client Process Executive Kernel Hardware Advanced Operating Systems

44. More On Microkernels • Microkernels were the research architecture of the 80s • But few commercial systems of the 90s really use microkernels • To some extent, “microkernel” is now a dirty word in OS design • Why? Advanced Operating Systems

45. Main Issue • What should be in the Kernel? • Different designs give different answers. • How to implement the system efficiently? • Some people think Micro kernel is slow • Micro kernel construction paper argue other way. Advanced Operating Systems

46. Apache SQL Server FIXED Abstractions Interface Hardware Exokernel • Traditional operating systems fix the interface and implementation of OS abstractions. • Abstractions must be overly general to work with diverse application needs. Traditional OS Advanced Operating Systems

47. The Issues • Performance • Denies applications the advantages of domain-specific optimizations • Flexibility • Restricts the flexibility of application builders • Difficult or impossible to implement own resource management abstractions. • Functionality • Discourages changes to the implementations of existing abstractions since it is used by different applications Advanced Operating Systems

48. Performance • Example: A DB can have predictable data access patterns, that doesn't fit with OS LRU page replacement, causing bad performance. • Cao et al. Found that application-controlled file caching can reduce running time by as much as 45%. • There is no single way to abstract physical resources or to implement an abstraction that is best for all applications. • OS is forced to make trade-offs • Performance improvements of application-specific policies could be substantial Advanced Operating Systems

49. The Solution • Separate protection from management • Allow user level to manage resources • Application libraries implement OS abstractions • Exokernel exports resources • Low level interface • Protects, does not manage • Expose hardware Advanced Operating Systems

50. ExokernelPhilosophy • Applications know better than Operating Systems what the goal of their resource management decisions should be • Applications should be given as much control as possible over those decisions • Implementation view Exokernel Frame Buffer | TLB | Network | Memory | Disk HW Advanced Operating Systems