1. Operating Systems: Wrap-Up Questions answered in this lecture: What is an Operating System? Why are operating systems so interesting? What techniques can I borrow when building systems? UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department CS 537 Introduction to Operating Systems Andrea C. Arpaci-Dusseau Remzi H. Arpaci-Dusseau

2. What have we learned? Operating System has two roles Standard library: Simplify use of resources w/ abstractions CPU: processes and threads –locks, semaphores, cv for synchronizing/communicating Memory: virtual address space Disks: files and directories Resource manager: Mechanism vs. Policy How to share CPU –dispatcher performs context-switches between processes –Scheduler decides which to run (SCTF, RR, multi-level feedback) How to share memory –paging and segmentation for protection, swapping to avoid thrashing –LRU, 2Q, working sets to determine which pages to replace How to allocate space on disk –layout (e.g., extents vs index) and scheduling for performance, journaling for consistency, RAID for reliability

3. Why are Operating Systems so Interesting? Challenging? Requirements not precisely defined Unknown workloads –Don’t know ahead of time: how long job will run, how much memory it will allocate, which pages it will reference, which files it will create, … –When know future behavior, can sometimes implement an optimal algorithm (e.g., SCTF, OPT) –Heuristic: Use past to predict future –What will future workloads look like? Conflicting metrics: performance, space overhead, reliability, consistency, power consumption, … –No one algorithm does best for all (e.g., contiguous allocation: best sequential performance but large external fragmentation; journaling: on-disk consistency, but performance overhead) –Which metrics will future users care about?

4. Why are Operating Systems so Interesting? Challenging? Requirements not precisely defined Changing technology changes assumptions –Hardware gets faster and cheaper, relative rates are important CPU improving faster than memory or disk Page faults and disk accesses relatively more expensive –New storage devices Flash, NVRAM: better random access behavior than disks

5. Why are Operating Systems so Interesting? Challenging? Large, complex system to implement Dealing with low-level hardware is painful Managing concurrency is difficult (race conditions, deadlock) Extend legacy code Coordinate many developers Time-to-market pressures

6. System Design Lessons What are some of the lessons that you can bring to other large software projects? Learn from previous systems Study what worked well and what did not –Long chain of Unix derivations from Multics Plan to throw one implementation away Build prototype first Incorporate prototype into schedule Revisit design decisions after system is in use –Can measure performance with real workload

7. System Design Lessons Defining the right abstractions is key Easier to conceptualize and debug Guidelines –Do not hide power of lower layers –Make common case fast –Should have known (predictable) cost –Separate mechanisms and policy –Leverage modules that work well

8. System Design Lessons Make your system as simple as possible Easier to maintain Easier to implement correctly –“There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” -- C.A.R. Hoare Potentially faster performance –Optimize for well-defined inputs –Too general --> too slow Remove features when in doubt!

9. Enjoy your winter break!