multicore oses
play

Multicore OSes Looking Forward from 1991, er, 2011 David A. - PowerPoint PPT Presentation

Multicore OSes Looking Forward from 1991, er, 2011 David A. Holland, Margo I. Seltzer { dholland, margo } @eecs.harvard.edu May 11, 2011 The Scenario Physical limits have been reached. Hardware isnt getting faster any more. To go


  1. Multicore OSes Looking Forward from 1991, er, 2011 David A. Holland, Margo I. Seltzer { dholland, margo } @eecs.harvard.edu May 11, 2011

  2. The Scenario • Physical limits have been reached. • Hardware isn’t getting faster any more. • To go faster we’re going to have to run in parallel. 1 HotOS / May 11, 2011

  3. The Scenario • Physical limits have been reached. • Hardware isn’t getting faster any more. • To go faster we’re going to have to run in parallel. Parallel code is hard! 1 HotOS / May 11, 2011

  4. The Scenario • Physical limits have been reached. • Hardware isn’t getting faster any more. • To go faster we’re going to have to run in parallel. Parallel code is hard! Scalable parallel code is harder! 1 HotOS / May 11, 2011

  5. The Scenario • Physical limits have been reached. • Hardware isn’t getting faster any more. • To go faster we’re going to have to run in parallel. Parallel code is hard! Scalable parallel code is harder! CRISIS!!!!!! 1 HotOS / May 11, 2011

  6. Meh. 2 HotOS / May 11, 2011

  7. Ok, it’s not quite 1991. From software, multiprocessor ≅ multicore. Lessons from the past twenty years: • Shared-memory code with locks doesn’t scale. • Hardware will end up shared-nothing. • Programming will involve message passing. 3 HotOS / May 11, 2011

  8. Ok, it’s not quite 1991. From software, multiprocessor ≅ multicore. Lessons from the past twenty years: • Shared-memory code with locks doesn’t scale. • Hardware will end up shared-nothing. • Programming will involve message passing. Let’s skip the bankruptcy filings and go straight to messages. 3 HotOS / May 11, 2011

  9. Lightweight messages and channels Di ff erent programming paradigm. Has some chance of scaling. Not actually new: • Communicating Sequential Processes • pi calculus • Erlang • goroutines 4 HotOS / May 11, 2011

  10. What It Looks Like (in “C”) chan <- value; /* send on channel */ value <- chan; /* receive from channel */ Comparable to procedure calls. choose { option x <- c1: foo(x); break; option x <- c2: bar(x); break; } Like select() . start { baz(); } Makes a new thread. 5 HotOS / May 11, 2011

  11. The Way Forward We need whole systems built this way: language... and kernel... and applications. Not just one research system, either. 6 HotOS / May 11, 2011

  12. The Way Forward We need whole systems built this way: language... and kernel... and applications. Not just one research system, either. Let’s talk about kernels. (But don’t worry; I’m not advocating Erlang.) 6 HotOS / May 11, 2011

  13. Channel OS Architecture • System calls will be messages. • This enables new OS structures. • Also need a whole new kernel based on channels... 7 HotOS / May 11, 2011

  14. Foreseeable Issues... • Implementing choice. • Waiting for channels to become ready. • What does virtual memory look like? • Too much parallelism? • Partial failure. • Scheduling. (and of course scaling is still hard) 8 HotOS / May 11, 2011

  15. Project State → hot air vapourware slideware demoware software abandonware 9 HotOS / May 11, 2011

  16. Multicore OSes Looking Forward from 1991, er, 2011 David A. Holland, Margo I. Seltzer { dholland, margo } @eecs.harvard.edu

Recommend


More recommend