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
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
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
such as
5.2.2 Experimental Setup
Our experimental infrastructure consists of
2.0GHz 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.3Linux. 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:
1Writing 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
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
7
