From: David Coleman (dcoleman_at_cs.washington.edu)
Date: Mon Mar 01 2004 - 15:47:50 PST
Denali is an interesting system. No one will claim that the goals are
too modest. However, I’m honestly not quite sure what the point is. It
almost seems like there were two independent goals: implementing a good
isolation kernel and making that kernel scalable. A solid isolation
kernel is an obviously useful thing. Scaling it to 10000 simultaneous
VMs I’m not so sure about.
It was surprising how much this system reminded me of the Exokernel
approach. Even though it explicitly differs in the area of protected
sharing by assuming that sharing between VMs isn’t necessary or even
desirable, it is still similar. In general I like the concept of minimal
kernels on top of a thin hardware layer for specialized application
support. Webservers, databases, and obviously Quake II servers all
probably feel that the OS gets in their way and would like to deal with
the hardware more and OS high-level abstractions less.
Unlike Disco, Denali puts more of the load/work on the operating system
or application that is running in the VM. By more or less requiring that
guest OSes and applications be written somewhat specifically for Denali,
it lessens its usefulness. For instance, the virtual timer interrupt not
keeping true physical time requires that applications or guest OSes be
modified to deal with that. Batch processing of interrupts seems like a
very useful idea for significantly improving performance. However, you
can only get away with that if you aren’t reflecting the actual
underlying hardware and are instead projecting a virtual architecture.
Denali also benefits from (almost requires) cooperative multitasking.
VMs need to release their CPU time when idle. They are rewarded if they
do so. The gatekeeper approach keeping a set of admitted machines ready
to run somewhat bothers me but I think I see the logic – you really
don’t want your ready list to contain 9999 VMs.
I’m not sure that the disk performance limit was due to the PCI bus or
the ATAPI bus. My hunch is that a SCSI implementation would have worked
better. SCSI releases the bus during commands freeing it up for other
commands to go to other devices while the original device is gathering
its data. It used to have much better overlapped I/O performance than ATAPI.
I’m not sure how Denali will be used in the long-term. I looked at Disco
whose goal is backward compatibility and saw obvious and immediate uses
(hence VMWare). I look at Denali and see an interesting and surprising
(in its effectiveness) system, but the usage requirements seem to be
self-defeating.
This archive was generated by hypermail 2.1.6 : Mon Mar 01 2004 - 15:43:33 PST