Saturday, May 21, 2011

The 2011 HotOS proceedings are online

I've been working my way through the proceedings of the 2011 HotOS Workshop. In addition to the online proceedings, Program Chair Matt Welsh of Google has posted several very interesting essays about the conference on his blog.

I really like the format that this workshop used of having 5-page papers. The 5 page limit is long enough to provide significant information about the research team's ideas, but short enough to force the writers to concentrate on the major ideas and not get bogged down in detail (though some of the papers are pretty dense). Overall, I've found the papers to be very clear and well-written, and I'd like to particularly recommend a few of them:

  • Mind the Gap: Reconnecting Architecture and OS Research. This paper suggests that operating system researches have become stuck in a rut, and are no longer helping to drive advances in computer system hardware:

    a typical OS paper usually uses the phrase "on commodity hardware." As a community, we assume we are stuck with whatever flaws the hardware has.

    The authors offer several examples of ideas in which they feel OS research could contribute to hardware enhancements, including: distributed/multicore messaging, efficient context switching, cache management, and instrumentation. But their goal is larger, to try to "close the gap" and encourage computer system researchers and systems software researchers to collaborate more closely.

  • Multicore OSes: Looking Forward from 1991, er, 2011. This paper makes some broadly similar points to the Mind The Gap paper, but focuses specifically on the increasing prevalence of multicore processors. The authors urge systems software researchers to review their history:

    the parallel supercomputers of the 1980's and 1990's exhibited all the same scaling limitations and ensuing software issues that we expect to see in multicore systems. Rather than waste time repeating that history, we should look at where that work led. ... experience in that sector says that conventional thread programming using locks and shared memory does not scale ... we should be looking to programming models, concurrency paradigms, and languages that natively support, or are based entirely on, messages rather than shared memory.

  • It's Time for Low Latency. This team focuses on a very specific problem: messaging latency:

    Network latency has been an increasing source of frustration and disappointment over the last thirty years. While nearly every other metric of computer performance has improved drastically, the latency of network communication has not. System designers have consistently chosen to sacrifice latency in favor of other goals such as bandwidth, and software developers have focused their efforts more on tolerating latency than improving it.

    Using some simple measurements, the authors suggest that it is not unreasonable to aim for 1-2 orders of magnitude improvements in latency (for those unfamiliar with this terminology, this means ten to one hundred times faster) in the short term. They argue, and I agree, that this would allow dramatic breakthroughs in many systems and techniques. In what may be a controversial proposal, they contend that current computer system design is pointed in the wrong direction:

    In recent years some NIC vendors have attempted to offload as much functionality as possible from the CPU to the NIC, including significant portions of network protocols, but we argue that this is the wrong approach. For optimal performance, operations should be carried out on the fastest processor, which is the main CPU; cycles there are now plentiful, thanks to increases in the number of cores.

    From experience, I know that it's quite common, when performing distributed system benchmarks, to encounter situations where the individual systems have plentiful CPU, memory, and disk resources, but the overall system is bottlenecked because the networking libraries can't run fast enough. Networking performance improvements have tremendous potential.

  • Disks Are Like Snowflakes: No Two Are Alike. This paper came totally out of left field for me; I wonder how many other people were as shocked and fascinated by it as I was? The authors break the news, which they claim has been known for years, but somewhat concealed, that disk drives have tremendous complexity and variability in their behavior:

    every disk has, by design, unique performance characteristics individually determined according to the capabilities of its physical components; for a given system setup and workload, and for the same corresponding physical regions across disks, some disks are slower, some disks are faster, and no two disks are alike.


    the root cause is manufacturing variations, especially of the disk head electronics, that were previously masked and are now being exploited. Like CPUs that are binned by clock frequency, different disk heads can store and read data at different maximum linear densities. Instead of only using each head at pre-specified densities, wasting the extra capabilities of most, manufacturers now configure per-head zone arrangements, running each head as densely as possible. We refer to this approach as adaptive zoning.

    The authors describe their work to explore these behaviors, by measuring different devices in minute detail, using several benchmarks of clever design, and then conclude by pointing out half-a-dozen ways in which this basic incorrect assumption about disk drive behaviors calls for a re-thinking of many basic algorithms and data-handling techniques.

I've only touched on the richness of this conference: there are some 35 different papers, covering a broad range of systems software topics, and most of them are very high quality and well worth your time. It's exciting to see that the systems software research community remains alive and active; there was widespread concern a few years ago that this field was dying out, but conferences such as these make it clear that there is still a long way to go and lots of fascinating work to be done.

No comments:

Post a Comment