展开查看详情
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