1. Advanced Operating Systems
(CS 202)
Distributed OS– intro and discussion
Feb. 8, 2016
2. Overview
• Hardware is changing, so software
must too
– Multicores are here to stay
– Architectures are heterogeneous
– Applications are unpredictable unlike
specialized systems
• How do operating systems scale?
• Do we need new OS architectures?
2
3. Landscape/motivation
• Systems are diverse
– different implementations require different tradeoffs
• Some nice examples
• Cores are increasingly diverse
– Different general purpose cores
– Accelerators and specialized processors
– Typically cannot share an OS with such differences
• Interconnects matter: within cores and across
cores
3
4. What has gone on before?
• Early on, locks were not so expensive
– Just use them
• Hardware evolved, memory expensive
– Large caches
– Cache coherence
– NUMA machines
– Increasing gap between memory and
processor
– Shared memory expensive!
4
5. Older SMP OS projects
• E.g., Tornado
• Locality matters
• Customize OS to underlying hardware
– But now we have high diversity
– Cannot have one size fit all
• Use replication as an optimization
• Still good principles
5
6. What we will cover
• Many argue that we need new models
– Mostly sharing is bad, try to have per core data
structures
– Barrelfish paper as a representative
• On the other hand, Linux scalability paper
shows that maybe conventional OS model
still works
• Finally, we will look at how the scheduler
should be adapted (wasted cores paper)
6
7. Barrelfish Motivation
• Messages cost less than shared memory
– Surprising? Why?
– Actually, this was a religious war in early
operating systems
– Needham et al showed they are duals
• May have to give up cache coherence
– To scale! Already seeing some
• Messages getting easier (OS’s respond to
interrupts/messages)
7
8. Discussion
• Well written paper, with very nice motivation
– But also deep and full of technical meat
• “Barrelfish is a point in the multikernel desgin space”
– – others possible
• Microkernel (and even exo-kernel) flavor?
– Isolating hardware specific primitives
– Customizing implementation for them
– Let OS manage them
• CPU driver and event monitor
– Nice from software engineering perspective
– But harmed performance
8
9. Discussion continued
• Processes as dispatchers (similar to
scheduler activations)
• Capability based management of
memory
– Similar to exo-kernel
• Supporting shared address space
– Share hardware page tables? Or
– Replicate and maintain consistency?
9
