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

multicore oses
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

Multicore OSes

Looking Forward from 1991, er, 2011

David A. Holland, Margo I. Seltzer

{dholland, margo}@eecs.harvard.edu May 11, 2011

slide-2
SLIDE 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

slide-3
SLIDE 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

slide-4
SLIDE 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

slide-5
SLIDE 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

slide-6
SLIDE 6

Meh.

2 HotOS / May 11, 2011

slide-7
SLIDE 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

slide-8
SLIDE 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

slide-9
SLIDE 9

Lightweight messages and channels

Different programming paradigm. Has some chance of scaling. Not actually new:

  • Communicating Sequential Processes
  • pi calculus
  • Erlang
  • goroutines

4 HotOS / May 11, 2011

slide-10
SLIDE 10

What It Looks Like (in “C”)

chan <- value; /* send on channel */ value <- chan; /* receive from channel */

Comparable to procedure calls.

choose {

  • ption x <- c1: foo(x); break;
  • ption x <- c2: bar(x); break;

}

Like select().

start { baz(); }

Makes a new thread.

5 HotOS / May 11, 2011

slide-11
SLIDE 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

slide-12
SLIDE 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

slide-13
SLIDE 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

slide-14
SLIDE 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

slide-15
SLIDE 15

Project State

→ hot air vapourware slideware demoware software abandonware

9 HotOS / May 11, 2011

slide-16
SLIDE 16

Multicore OSes

Looking Forward from 1991, er, 2011

David A. Holland, Margo I. Seltzer

{dholland, margo}@eecs.harvard.edu