Introduction: How to read and write systems papers

CPS210Spring 2006

Course basics What is CPS210 about?

Operating systems research Who should take it?

Graduate students and smart undergrads Who is the instructor?

Landon Cox (lpcox@cs.duke.edu) Duke systems faculty since September ‘05 Duke alumnus (Trinity, class of ’99) Recently received my Ph.D. from Michigan

(Dec. ‘05) More at the end of class

Outline

Hints for Computer System Design Butler Lampson

An Evaluation of the Ninth SOSP Submissions Roy Levin and David Redell

Course mechanics

Hints for designing systems

What is a system? Components, interconnections Interfaces, environment

Systems do something for their environs Exhibit this behavior via interface

Cleanly divides the world in two Parts of the system + the environment

Systems from 10,000 feet

Environment aka “the client”

System

Component

Component

Component

Com

pon

en

t

Why is designing systems hard? Emergent properties

Can’t predict all component interactions Millennium bridge

Synchronized stepping leads to swaying Swaying leads to more forceful synchronized

stepping Leads to more swaying …

Propagation of effects Incommensurate scaling Trade-offs

Why is designing systems hard? Emergent properties Propagation of effects

Want a better ride so increase the tire size Need a larger trunk for the larger spare Need to move the back seat forward Need to make front seats thinner Leads to worse driver comfort than before

Incommensurate scaling Trade-offs

Why is designing systems hard? Emergent properties Propagation of effects Incommensurate scaling

Consider the giant mouse Weight ~ size3 (volume) Bone strength ~ size2 (cross section area) An elephant sized mouse is not

sustainable Trade-offs

Why is designing systems hard?

Emergent properties Propagation of effects Incommensurate scaling Trade-offs

“Waterbed effect” Push on one end, and the other goes up Spam filters and smoke detectors False positives vs false negatives

Why is designing systems hard?

Emergent properties Propagation of effects Incommensurate scaling Trade-offs In the immortal words of HT Kung

“Systems hard. Must work harder.”

Lamport’s hints for design

Behold, the “summary of slogans”

Or, put another way … Three design goals (the why axis)

Making it work (functionality) Making it fast enough (speed) Making sure that it keeps working (fault

tolerance) Three design constraints (the where axis)

Completeness Proper interconnections/interfaces Building an implementation

“Separate the normal, worst case”

Hard for math/theory people to accept More natural for engineers Full disclosure: I was a math major

Make common case fast, corner case correct Corollary

Often not worth optimizing the corner case Depends on just how painful the corner case is

Example: disconnected operation in Coda

“End-to-end” Don’t try to be all things to all people

Functionality imposes trade-offs on others You’ll get it right for a few, wrong for most

Keep systems lean, simple, and efficient Allow clients to weigh their own trade-offs They know their needs better than you

Example: Internet and IP Simple protocol allowed others to build on

top

“Caching answers” Store expensive computations’ results Must maintain consistency of cache

Are stored answers correct? Must manage cache residency

Which answers deserve to be in the cache?

Example: buffer cache Going to disk takes ~ 10 milliseconds Going to memory takes ~ microseconds

“Use hints” Hints are like cached answers Two differences

Hints are only mostly right (may be wrong) Can be checked against the truth Not always reached by associative lookup

Example: file directories Files in the same directory are likely related Collocating them on-disk can improve

access time

“Compute in background” In systems, procrastination is encouraged Defer work as long as possible

You might end up not having to do it Variation of “closest-deadline-first”

Especially true for performance Keep the critical path as short as possible

Example: writing files back to a server Most files are short-lived Wait to see if they’re deleted before shipping

“Log updates” Writing to a log is very efficient

Only need to maintain start, end addresses Simply append to the end

Logging preserves write order Log cannot be corrupted by failures

Can always get back to a consistent state Very useful for performance, fault

tolerance Example: databases

“Static analysis”

Better to fail during design than run-time Especially useful for avoiding bugs

Examples Type-safe languages, BAN logic

Caveat This is usually really hard State spaces grow extremely fast

Outline

Hints for Computer System Design Butler Lampson

An Evaluation of the Ninth SOSP Submissions Roy Levin and David Redell

Course mechanics

Motivating your system What problem are you solving?

Why is it important? What is state-of-the-art (SOA)?

Why is SOA inadequate? What is new about your approach?

How does it differ from SOA? Bottom line:

Why should I care about this? Why is this different from what I’ve

already seen?

Describing your system What are the architectural/design

goals? What assumptions are you making?

Why are those assumptions reasonable? What were the alternative approaches?

Why didn’t you take those approaches? Bottom line:

Why should I believe that this will work?

Evaluating your idea Did you implement the architecture?

Which parts? Does it achieve the design goals?

Did it change your original design? Does it expose architectural limitations? Bottom line:

Does the system solve the original problem? Does the system introduce any new

problems?

Outline

Hints for Computer System Design Butler Lampson

An Evaluation of the Ninth SOSP Submissions Roy Levin and David Redell

Course mechanics