Intel IRP-TR-03-10 warranty Time for Compiling Linux Kernel, 5.2Internet Suspend/Resume

			Lookaside Device State
Bandwidth	No Device	2.4.18	2.4.17	2.4.13	2.4.9	2.4.0
100 Mb/s	287.7 (5.6)	292.7 (6.4)	324.7 (16.4)	346.4 (6.9)	362.7 (3.4)	358.1 (7.7)
		[-1.7%]	[-12.9%]	[-20.4%]	[-26.1%]	[-24.5%]

10 Mb/s

388.4(12.9)

282.9(8.3)

[27.1%]

364.8(12.4)

[6.1%]

402.7(2.3)

[-3.7%]

410.9(2.1)

[-5.8%]

421.1(12.8)

[-8.4%]

1 Mb/s

1148.3 (6.9)

424.8(3.1)

[63.0%]

543.6(11.5)

[52.7%]

835.8(3.7)

[27.2%]

1012.4 (12.0)

[11.8%]

1094.3 (5.4)

[4.7%]

100 Kb/s 9348.8 (84.3)

884.9(12.0)

[90.5%]

3011.2 (167.6)

[67.8%]

5824.0 (221.6)

[37.7%]

7616.0 (130.0)

[18.5%]

8356.7 (226.9)

[10.6%]

These results show the time (in seconds) taken to compile the Linux 2.4.18 kernel. The column labeled “No Device” shows the time taken for the compile when no portable device was present and all data had to be fetched over the network. The column labeled “2.4.18” shows the results when all of the required data was present on the storage device and only meta-data (i.e. stat information) was fetched across the network. The rest of the columns show the cases where the lookaside device had versions of the Linux kernel older than 2.4.18. Each data point is the mean of three trials; standard deviations are in parentheses. The numbers in square brackets give the “win” for each case: that is, the percentage improvement over the “no device” case.

Figure 6. Time for Compiling Linux Kernel 2.4.18

to 543.6 seconds).

On a slow LAN (10 Mb/s), lookaside caching con- tinues to give a strong win if the portable device has current data: 27.1% (388.4 seconds to 282.9 seconds). The win drops to 6.1% (388.4 seconds to 364.8 sec- onds) when the portable device is one version old (2.4.17). When the version is older than 2.4.17, the cost of failed lookasides exceeds the benefits of successful ones. This yields an overall loss rather than a win (rep- resented as a negative win in Figure 6). The worst loss at 10 Mb/s is 8.4% (388.4 seconds to 421.1 seconds).

Only on a fast LAN (100 Mb/s) does the overhead of lookaside caching exceed its benefit for all device states. The loss ranges from a trivial 1.7% (287.7 sec- onds to 292.7 seconds) with current device state to a substantial 24.5% (287.7 seconds to 358.1 seconds) with the oldest device state. Since the client cache man- ager already monitors bandwidth to servers, it would be simple to suppress lookaside at high bandwidths. Although we have not yet implemented this simple change, we are confident that it can result in a system that almost never loses due to lookaside caching.

5.2Internet Suspend/Resume

5.2.1Benchmark Description

Our second benchmark is based on the applica- tion that forced us to rethink the relationship between portable storage and distributed file systems. Internet Suspend/Resume (ISR) is a thick-client mechanism that allows a user to suspend work on one machine, travel to another location, and resume work on another machine there [9]. The user-visible state at resume is exactly what it was at suspend. ISR is implemented by layer- ing a virtual machine (VM) on a distributed file system. The ISR prototype layers VMware on Coda, and repre- sents VM state as a tree of 256 KB files.

A key ISR challenge is large VM state, typically many tens of GB. When a user resumes on a machine with a cold file cache, misses on the 256 KB files can result in significant performance degradation. This overhead can be substantial at resume sites with poor connectivity to the file server that holds VM state. If a user is willing to carry a portable storage device with him, part of the VM state can be copied to the device at

6