I’m in lovely Boston this week. Originally I was supposed to attend the Xen Summit North America 2008, MMCS 2008, and USENIX 2008, but I ended up missing the Xen Summit completely and making a just-in-time appearance at MMCS, due to some trouble at home. Thankfully everything is fine now.
At the Xen Summit my colleague Todd DeShane presented our preliminary results of a quantitative comparison of Xen and KVM. I’m sorry I missed the summit, by all accounts I heard it was a pretty fun event.
At USENIX, I presented a poster on our SCIMITAR work which introduces the notion of “virtual memory for I/O devices”. It got generally positive feedback, including a few “wow, that’s pretty cool” comments. I kept wishing our prototype was at a stage where we could finally have some results, but as I told those who asked, if we had had any results, I would’ve been presenting a paper, not a poster…
At MMCS, I participated in a panel on “Platform Management—Coordination or Not?”, moderated by Intel’s Milan Milenkovic. Platform management is a subject that comes up fairly often in my day-to-day work, so it was fun spending some time thinking about it and trying to come up with an appropriate position statement for the panel. The way I see it, the primary function of a panelist is to encourage the audience to think, and the easiest way to do that is to be a bit controversial. A panel where everyone—both panelists and audience—agree on everything, is a dull affair.
Here is my MMCS 2008 panel position statement—paraphrased, not transcribed! For context, you probably want to read the panel description first.
“Hello everyone,
Thank you for inviting me to participate in the panel. When thinking about the questions Milan raised with regards to platform management, I had a bit of a problem coming up with a suitable position statement. As it happens, I either wear or used to wear many different hats. I used to work on real applications. I currently work on operating systems and hypervisors, and occasionally I dabble in computer architecture. I wondered, what kind of insight could I get from each of these perspectives?
From the application writer’s perspective, there are three different classes of application writers: those who do not care about the platform at all, those who think they know everything best but actually don’t, since they only have localized knowledge, and those that really do know everything best.
From the operating systems developer perspective, you don’t get too many kernel developers who don’t care about the platform, so we can leave those out. That leaves two classes: those who think they know best, but are wrong since again they only have localized knowledge (think virtual machines), and those who really do know best.
From the hypervisor’s developer perspective, well, really, hypervisors are just a new name for operating systems!
From the computer architecture folks perspective, well, they just know everything best. Having said that, they have a whole lot of legacy stuff to support which severely constrains what they can and want to do.
Now, having shared with you all of these perspectives, let me share something else: none of it actually helped me come up with a good answer to the question’s Milan raised.
So I tried a different approach. I assume most of you are familiar with the end-to-end argument in system design, which is usually applied to networking. Well, what does the end-to-end argument tell us about platform management? As far as I can apply it, it tells us that we should let each layer do what it knows how to do best. Not a very satisfying answer.
Well, let’s try a different approach then. Programming language folks like to say that programming languages should make “the simple things easy, and the hard things possible”. And here I think we may have actually hit on something. How does this apply to platform management? The way I interpret it, it means two things. First, that each layer in the system should make sensible decisions on its own. Second—more importantly, and hopefully somewhat controversially—that each layer should provide a “chicken switch”.
What’s a chicken switch? It’s a term you sometimes hear in hardware design. It means that when you have all these new functionality in your design, which is not as well tested (or thought out…) as the old, reliable stuff, you usually enable it (it’s new and shiny after all), but you also provide a way of “shouting chicken”. A way of disabling the new stuff and going back to the old, proven way of doing things.
By analogy, I claim that the most important feature a platform component can have when it comes to management, is a way for the layer above or below it to tell it to “do nothing, and get out of the way”.
Thanks you.”
Muli Ben-Yehuda's journal 