From: shearerje_at_comcast.net
Date: Sat Feb 28 2004 - 10:42:51 PST
Disco is an emulation layer that separates a heterogeneous mix of commodity operating systems from an underlying multiprocessor architecture. Disco emulates kernel mode behavior while actually running the commodity operating system in supervisor mode inside a virtual machine. This allows Disco to remain in control and preempt the operating system if necessary, but also requires that Disco provide an emulation of kernel privileges such as memory management, trap handling and I/O interfaces.
Disco does not run just any commodity operating system right out of the box. The OS must be capable of running directly on the type of processor used in the underlying nodes (MIPS R10000 in this paper) and is easiest to modify if it has a Hardware Abstraction Layer. Changes to the HAL were necessary to substitute new Disco-friendly device drivers.
Disco allocates CPU resources to the OS and actually runs most of the OS directly on the CPU (as opposed to emulating every machine instruction). Key exceptions are Translation Look-aside Buffer (TLB) modifications and I/O. Memory is accessed through a two-tiered indirection where the local “physical pages” that the OS expects to call are actually a TLB-implemented indirection to the actual machine pages that may be on any node. Disco monitors TLB misses and will replicate or copy machine pages to the actual local node (updating the “physical page” indirection accordingly) if this will speed up over-all access. Disco uses Copy on Write, so an example of where Disco WONT move the page is if more than one virtual machine frequently writes to it. Disco also simulates the hard drives themselves so that it can arbitrate contention between virtual machines. Unfortunately, there is a kernel segment (KSEG0) in the chosen multiprocessor environment that cannot be managed in the same way as all of the rest of me
mory, so Disco needed some special case features to work around it.
The paper had two primary weaknesses. First, it looked to me like the first three sections were written by three independent people and the repetition was almost unbearable. My advice to anyone who has not yet read the paper is to just start with section 4. Second, I was disappointed that the authors chose as their platform a system that is not actually available yet and thus had to resort to a simulation. This always makes me suspicious of the fidelity of the experiment. On the other hand, if they were able to affect the platform design by feeding back their experiences (e.g., regarding KSEG0), then maybe this was a good thing.
This archive was generated by hypermail 2.1.6 : Sat Feb 28 2004 - 10:42:57 PST