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
& 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 Use static analysis
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 Safety First 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 Log updates
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. “The unavoidable price of reliability is simplicity.”
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