From: Ian King (iking_at_killthewabbit.org)
Date: Sun Feb 29 2004 - 22:25:15 PST
The authors describe a software layer that virtualizes an underlying
multiprocessor to one or more commodity operating systems, with the goal of
allowing these operating systems to take advantage of the distributed computing
of a NUMA machine without the need to address that architecture's challenges.
The authors cite the enormous investment made by software vendors in operating
systems, and suggest that they are unlikely to invest further resources to
target their operating systems to experimental, high-end systems such as the
FLASH system targeted by Disco; further, this paper touches on other "minimal"
OS work that can serve specialized purposes that can coexist with commodity
operating systems on a multiprocessor system.
It is a shame that this paper was not supported by work on the target platform,
but rather on simulation. However, it is still quite interesting in its
approach to compromises in the interest of performance and convenience. Most
significant is the transparent 'mirroring' of memory pages between processor
spaces to avoid NUMA latencies - without this, it is unlikely Disco would be
effective. "Pragmatic" optimizations in virtualization of networking also
contribute to performance, and Disco achieves a surprisingly low overhead
because of these clever 'back doors.'
This is yet another example of segregation of functionality and layering leading
to a system that successfully addresses a given challenge without becoming mired
in performance problems, as compared to a monolithic system that addresses the
challenge, and only that challenge, directly. Disco achieves the "right" level
of abstraction between the hardware and existing operating systems, so as to
minimize (but not eliminate) the need for changes in those operating systems to
function efficiently on a completely new hardware platform; this is probably
more through empiricism than theoretical purity, but all's well that ends well.
While a purist might cringe at the 'special cases' that 'violate' the principle
of a purely abstracted virtual machine, the pragmatic engineer (such as this
reviewer) must nod acknowledgement at the authors' choices of the right places
to optimize performance in a generic fashion, i.e. that could easily be
transported across multiple platforms. (Only the MIPS-related kernel memory
hack is truly platform-specific, and someone at NEC should be beaten soundly for
its necessity.) While the paper does not elucidate the mechanisms by which one
might invoke some of these optimizations (e.g. local vs. global I/O), one must
hope that they are reasonably simple and accessible.
The authors' comparison of Disco with the exokernel is very apt, and they
correctly differentiate them: Disco provides a uniform, virtual image of the
underlying hardware, while an exokernel does not seek to abstract that hardware,
only manage it for multiple customers. In essence, Disco conceals the details,
while an exokernel requires gory knowledge in the user-level libraries. I have
considered a multiprocessor based on the exokernel concept, and it would require
considerable cleverness in the user-level libraries - or, potentially, a
Disco-like layer to arbitrate, if not virtualize the underlying processor pool.
This archive was generated by hypermail 2.1.6 : Sun Feb 29 2004 - 22:46:19 PST