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