Reading

The reading schedule for this course will be intense. The readings are grouped into four major categories: complexity, performance, reliability, and security. Within each category, we will read papers that address that issue in the context of different portions of an operating system.

You should form a discussion group for talking about the papers. You should have three or four people in your group, and discuss each paper sometime before class meets. It is up to you if you want to meet just once a week or twice a week before each class, but you should discuss each paper. When you have formed a group, please send me email with a list of group members.

When discussing each paper, you are encouraged to consider the following questions: As you read, here are some questions you should consider:

  1. What problem are the authors trying to solve?
    • Why was the problem important?
    • Why was the problem not solved by earlier work?
  2. What is the authors solution to the problem?
    • How does their approach solve the problem?
    • How is the solution unique and innovative?
    • What are the details of their solution?
  3. How do the authors evaluate their solution?
    • What specific questions do they answer?
    • What simplifying assumptions do they make?
    • What is their methodology?
    • What are the strengths and weaknesses of their solution?
    • What is left unknown?
  4. What do you think?
    • Is the problem still important?
    • Did the authors solve the stated problem?
    • Did the authors adequately demonstrate that they solved the problem?
  5. What future work does this research point to?

You should be prepared to discuss these questions in class. For each paper I will ask for a volunteer to summarize and address a few of these questions in class.

Here are a few links to advice on reading papers:

Responsibilities

For every lecture, you will be reading one or two research papers. For each paper, you have four responsibilities:
  1. Read the paper
  2. Discuss the paper with your group
  3. Submit a short writeup about the paper
  4. Prepare to summarize the paper in class

Writeup

Before 9:30 am on day of class, please post your review to the blog at:
http://www.cs.wisc.edu/~cs736-1/blog
Your posting should contain:
  1. A one or two sentence summary of the paper
  2. A one description of the problem they were trying to solve
  3. A summary of the contributions of the paper
  4. The one or two largest flaws in the paper
  5. For performance papers, what was the high-level approach taken to improving performance? Give one example of another problem where the approach could be applied.
  6. For reliability papers, what kinds of faults (hardware, software, operator) can be tolerated and what kinds cannot be tolerated?

The writeup should not be more than a page in length. Late writeups will receive a zero grade.

Writeup Grading

What I’m looking for:
  • Does the review include all sections (summary, problem, contributions, flaws, relevance)
  • Are all assertions backed up (e.g. “X is a bad idea” is not acceptable, but “X is a bad idea because Y”) is acceptable
  • Is the review concise? The summary should be a few sentences and give the essence of the design in the paper, not the problem. (E.g., “This paper is about how to build a multiprocessor operating system” is not acceptable, but “This paper is about building a multiprocessor operating system by layering abstractions that mask the existence of multiple processors” is acceptable)
  • Did the student understand the material? Are there factual flaws in the review? For example, if the paper defines a term, does the student use it appropriately? As another example, if students state that a paper is relevant because modern operating systems do things the same way, is that true?
Assigning grades:
  • If the review does an excellent job on all four considerations, and provides genuinely insightful comments about the problem, contributions, flaws, or relevance, it should receive a check plus
  • If two or more of the four criteria are not met, the review should receive a check minus
  • Otherwise, it should receive a check.

A check plus is worth 1 point, a check is 3/4 point, a check minus is 1/2 point, and not turning a review in is worth zero points.

Reading List