From: David Coleman (dcoleman_at_cs.washington.edu)
Date: Mon Mar 01 2004 - 16:13:04 PST
Disco is an interesting system (OK, they’ve all been pretty interesting)
that implements a Virtual Machine Monitor on the FLASH NUMA
shared-memory multiprocessor computer system developed at Stanford.
The first thing that surprised me about Disco was that it used direct
execution on the real CPU. For some reason, I had always assumed an
interpreted model, but that would obviously be too slow. This is a
significant speed improvement but required minor modifications of the
code running in the VM in some cases. That is a requirement that
prevents running commodity OSes – a serious penalty for a system such as
this.
Because of the NUMA architecture, Disco had some additional problems to
solve that other VMMs running on single or multiprocessor systems with
shared memory would not have to face. It hid the NUMA-ness of the
architecture and presented the machine as a standard shared-memory
system. The ability for the hardware to detect hot pages is very useful
and a great idea. I’m not sure if other hardware platforms support this
– if not they probably should in these types of environments.
Probably the thing that surprised me the most about Disco was the
concept of sharing between virtual machines. I want very thick walls
between my VMs. For me, the whole point of running a VMM is to allow
multiple OSes to coexist without knowledge of the other and act
accordingly without any possibility of interacting with the others.
There were several changes made to IRIX to allow it run and run more
efficiently on this system. The HAL was patched for efficiency, the mbuf
management code was modified for efficiency, and the bcopy routine was
modified for efficiency. To really be useful, OSes must be able to run
out of the box. They obviously solved this problem in VMWare.
I was disappointed in the experimental results section simply because it
was run on a simulator instead of the actual hardware. When you are
dealing with the layers and complexity of this type of system, real
results are pretty important. Multiple VMs running on top of a VMM
running on top of a simulator running on another machine is just too
virtual for me.
This archive was generated by hypermail 2.1.6 : Mon Mar 01 2004 - 16:08:38 PST