Transcript last-lecture - Computer Sciences User Pages

UNIVERSITY of WISCONSIN-MADISON
Computer Sciences Department
CS 537
Introduction to Operating Systems
Andrea C. Arpaci-Dusseau
Remzi H. Arpaci-Dusseau
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?
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
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?
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
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
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
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
System Design Lessons
Make your system as simple as possible
•
•
Easier to maintain
Easier to implement correctly
–“T h e re a re tw o w a y s o f c o n s tru c
way is to make it so simple that there are obviously no
deficiencies and the other way is to make it so complicated that
t h e r e a r e n o o b v --i C.A.R.
o u s Hoare
d e fic ie n c
•
Potentially faster performance
– Optimize for well-defined inputs
– Too general --> too slow
•
Remove features when in doubt!
Enjoy your winter break!