suspend.
1
Lookaside caching can then reduce the per-
formance overhead of cache misses at the resume site.
A different use of lookaside caching for ISR is
based on the observation that there is often substantial
commonality in VM state across users. For example,
the installed code for applications such as Microsoft
Office is likely to be the same for all users running
the identical software release of those applications [3].
Since this code does not change until a software up-
grade (typically many months apart), it would be sim-
ple to distribute copies of the relevant 256 KB files on
DVD or CD-ROM media at likely resume sites.
Notice that lookaside caching is tolerant of human
error in both of the above contexts. If the user inserts
the wrong USB storage keychain into his machine at
resume, stale data on it will be ignored. Similarly, use
of the wrong DVD or CD-ROM does not hurt correct-
ness. In both cases, the user sees slower performance
but is otherwise unaffected.
Since ISR is intended for interactive work-
loads typical of laptop environments, we created
a benchmark called the Common Desktop Appli-
cation (CDA) that models an interactive Windows
user. CDA uses Visual Basic scripting to drive
Microsoft Office applications such as Word, Excel,
Powerpoint, Access, and Internet Explorer. It con-
sists of a total of 113 independently-timed operations
such as find-and-replace, open-document, and
worksheet-sort. Actions such as keystrokes, object
selection, or mouse-clicks are not timed.
5.2.2 Experimental Setup
Our experimental infrastructure consists of
2.0 GHz Pentium 4 clients connected to a 1.2 GHz
Pentium III Xeon server through 100 Mb/s Ethernet.
All machines have 1 GB of RAM, and run Red Hat
7.3 Linux. Clients use VMware Workstation 3.1 and
have an 8 GB Coda file cache. The VM is configured
to have 256 MB of RAM and 4 GB of disk, and runs
Windows XP as the guest OS. As in the previous
benchmark, we use the NISTNet network emulator to
control bandwidth.
5.2.3 Results
From a user’s perspective, the key performance
metrics of ISR can be characterized by two questions:
1
Writing the entire VM state to the portable device may take too long for a user in
a hurry to leave. In contrast, propagating updates to a file server can continue after the
user leaves.
• How slow is the resume step?
This speed is determined by the time to fetch and
decompress the physical memory image of the
VM that was saved at suspend. This is the smallest
part of total VM state that must be present to begin
execution. The rest of the state can be demand-
fetched after execution resumes. We refer to the
delay between the resume command and the ear-
liest possible user interaction as Resume Latency.
• After resume, how much is work slowed?
The user may suffer performance delays after re-
sume due to file cache misses triggered by his
VM interactions. The metric we use to reflect the
user’s experience is the total time to perform all
the operations in the CDA benchmark (this ex-
cludes user think time). We refer to this metric
as Total Operation Latency.
Portable storage can improve both resume latency
and total operation latency. Figure 7 presents our re-
sults for the case where a USB flash memory keychain
is updated at suspend with the minimal state needed
for resume. This is a single 41 MB file correspond-
ing to the compressed physical memory image of the
suspended virtual machine. Comparing the second and
third columns of this figure, we see that the effect of
lookaside caching is noticeable below 100 Mb/s, and is
dramatic at 100 Kb/s. A resume time of just 12 seconds
rather than 317 seconds (at 1 Mb/s) or 4301 seconds (at
100 Kb/s) can make a world of a difference to a user
with a few minutes of time in a coffee shop or a wait-
ing room. Even at 10 Mb/s, resume latency is a factor
of 3 faster (12 seconds rather than 39 seconds). The
user only pays a small price for these substantial gains:
he has to carry a portable storage device, and has to
wait for the device to be updated at suspend. With a
Hi-Speed USB device this wait is just a few seconds.
To explore the impact of lookaside caching on total
operation latency, we constructed a DVD with the VM
state captured after installation of Windows XP and the
Microsoft Office suite, but before any user-specific or
benchmark-specific customizations. We used this DVD
as a lookaside device after resume. In a real-life de-
ployment, we expect that an entity such as the comput-
ing services organization of a company, university or
ISP would create a set of VM installation images and
matching DVDs for its clientele. Distributing DVDs
to each ISR site does not compromise ease of manage-
ment because misplaced or missing DVDs do not hurt
7
