Hints for Computer System Design

1. Hints for Computer System Design Butler W. Lampson

2. System Design: Introduction • Designing a computer system is hard! • Is it like designing an algorithm? • Designers hesitate about unclear choices & how they affect • Flexibility • Performance • The freedom to make subsequent choices within the constraints of previous ones because: • OSs don’t partition into isolated subsystems very well • OS subsystems may interact in unexpected ways

3. System Design: Introduction • Other reasons it’s so hard: • Moore’s law • OSs don’t improve by a factor of 100 every decade • Backward compatibility • OSs are fundamentally different than standard apps. • Extremely large programs • UNIX: 1 Million lines of code • Windows: 29 million lines of code • OSs have to deal with potentially hostile users & at same time allow users to share information

4. System Design: Introduction • Even more reasons it’s so hard: • OSs live for a very long time • UNIX is over a quarter of a century old • Must prepare for hardware/software changes • OS designers do not have a good idea how their systems will ultimately be used • Email & web browsers came after UNIX • OSs have to run on multiple hardware platforms • OSs frequently have to be backward compatible

5. System Design: The Slogans

6. Functionality: The Interface • Do one thing well (keep it simple) • Don’t generalize • Extensible OS designs • Microkernels: general interface, few assumptions made about implementation • Exokernel: kernel provides resource protection, just exports hardware • Get it right • Make it fast • Don’t hide power • Virtualization: virtual hardware exposed is functionally identical to the underlying hardware • Exokernel: the high-performance of the hardware is just exported to the user

7. Functionality: The Interface • Use procedure arguments to provide flexibility in an interface • Leave it to the client • Monitors: locking & signaling mechanisms to very little, leaving all the real work to the client • Keep basic interfaces stable • Keep a place to stand if you must change interfaces (backward compatibility) • Examples: • Emulation library: microkernels emulate interfaces by trap redirection • Elephant file system: Keep One • Virtualization: VMM multiplexing at the granularity of an operating system

8. Functionality: Implementation • Plan to throw one away • Keep secrets (encapsulation) • Virtualization: • Hide the messy stuff like NUMA • Monitors • Allow access only at certain entry points • Use a good idea again • Divide and Conquer • RPC/LRPC/URPC: • Progression solved a problem in parts: cross-machine, cross-domain, better cross-domain (less kernel involvement)

9. Functionality: Completeness • Separate normal and worst case • The normal case must be fast • The worst case must make progress • RPC & its variations • Cross-domain common case • Cross-machine happens only sometimes • Specialization • Partial evaluation when possible • Replugging when necessary

10. Speed: Interface • Split resources • VMM: Multiplexing resources • Guest OSs aren’t even aware that they’re sharing • Use static analysis • Specialization (static): predicates known at compile time allows for partial evaluation • Dynamic Translation • Specialization (dynamic): at run-time predicates that hold for the remainder of execution or some bounded time period (packet filter interpreter)

11. Speed: Implementation • Cache Answers to expensive computations • Use hints • The Ethernet: exponential backoff • Links in web pages • When in doubt use brute force • Compute in background • Use batch processing • Soft timers: uses trigger states to batch process handling events to avoid trashing the cache more often than necessary • RCU: memory reclamation done in batches • Cleanup in log structured file systems: segment cleaning could be scheduled at nighttime.

12. Speed: Completeness • Shed load to control demand • SEDA • Adaptive load shedding • Apache • Bounded thread pool • Safety First • When allocating resources remember safety first • Avoid temptation to try to obtain optimum performance (instead try to avoid disaster) • Progression of kernel structuring approaches for extensibility • Microkernels, sandboxing, SPIN vs. Mach (some versions) & Chorus

13. Fault-tolerance • End-to-end • We’ll see this next! • Log updates • Logs can be reliably written/read • Logs can be cheaply forced out to disk, which can survive a crash • Log structured file systems • RAID5 in Elephant • Make actions atomic or restartable • RCU: changes are seen as atomic to all processes

14. System Design: Conclusion • Just remember: • Designing an OS starts with determining what it should do • The interface should be simple, complete, & efficient • There probably isn’t a “best” solution for even one part of any system • Just don’t choose a terrible solution • Have a clear division of responsibility among the parts

15. System Design: Quotes “Perfection is reached not when there is no longer anything to add, but when there is no longer anything to take away” --A. Saint-Exupery “The unavoidable price of reliability is simplicity.” --C. Hoare

16. System Design: References • Jon Walpole • “Hints for Computer System Design” Lampson. • Modern Operating Systems, Second Edition. Tannenbaum, pp. 855-894. • http://c2.com/cgi/wiki?SpiralModel • http://www.dpw.wau.nl/pv/temp/clipart/ • http://firstmonday.org/issues/issue7_11/tuomi/