- Paper 1: Chiueh et al, SOSP '99 PostScript PDF
- Paper 2: Kim et al, OSDI '00 PostScript PDF (BIG!)
You are to read, understand, and critically assess the papers. Questions
you may want to ask yourself for each of the papers:
- What problem is it trying to address
- How well does it address the issue
- How does it relate to other work? Does
it reference relevant other work (as far as you can tell), does it
do the other work justice?
- How technically sound is it? Does their argumentation, the
presented data convince you? Should they have been looking at other
issues?
- How good are the results?
- How good/deep is their analysis?
- How easy would it be to reproduce their results?
- How general are their results? Can they be applied to other
systems? Did we learn some general truth?
These are only hints, I am not asking you to explicitly answer all these
for each paper. However, you may find those questions helpful in
critically analysing the papers. Imagine you are a reviewer for a
conference to which the papers have been submitted, and you are to judge
their contribution to the field.
Note that all papers are in fact published (and therefore cannot be
all that bad :-)
Here are (very good) sample solutions, which were done in ``real-time''
by one of the students taking the exam:
- Sample report on Chiueh et al.
Other points the author could have made:
- user-level extensions are not protected from each other, nor
from the base code,
- the scheme does not allow extending extensions,
- time protection relies on an arbitrary global timeout value,
- it is not clear how this scheme maintains protection if
processes are multithreaded (and one can suspect it doesn't),
- the paper uses meaningless digits (e.g., 15.22 when they say
themselves that the standard deviation is 2%).
- Sample report on Kim et al
Other points the author could have made:
- tuning of other schemes (rather than using their authors'
"recommended values") might have improved their performance,
- they could have done some runs showing that the
automatically chosen steady-state partitioning of the buffers
performs indeed best,
- they should have commented on the (apparently?) sequential
accesses in the "other" graph of Fig 7b,
- their CPU-bound benchmark only gives a worst case value for
their overheads (so they could actually be lower),
- they could have commented on how reasonable it is to base
their definition of sequential access on access in increasing
logical block order.
Note: this is an exam, not betting on horses. It is dangerous to
guess what I might think of the paper, or to guess that
there'll be a good and a bad one. Papers are selected on other
criteria.
What to submit
You are to submit a report which summarises for each paper the basic
ideas behind their work. You are to give a critique of the technical
merits, achievements and shortcomings (if any). The papers are not
directly related, so you don't have to compare them (although feel free
to do a comparative analysis if you think it makes sense).
I am intentionally not specifying a length limit. However, I
strongly encourage you to be concise. Lengthy submissions will almost
certainly be unfocussed and waffly. I cannot imagine a decent job in
excess of 3000 words, and would imagine that a very good submission
would stay well below 2000 words total. If your report gets longer than
this you should step back and try to focus.
What I will be looking for
You will be marked on the level of understanding and critical analysis
portrayed in you submission. All relative to what can be reasonably
expected from you (I know that none of you have a PhD in OS yet :-)
1999 exam
You may find it useful to look at last year's
exam, and the sample reports provided there.
COMP9242,
School of Computer Science and Engineering,
University of New South Wales
This page is maintained by
gernot@cse.unsw.edu.au.
Last modified: Thursday, 01-Aug-2002 01:50:03 AEST
[an error occurred while processing this directive]