Test 1

The purpose of this test is to check how reordering files on disk affects boot time.

Test description

Test machine: KL1

Test environment:

• Kubuntu Gutsy KL1 with updates as of 2007-06-10, moved to other partition (hda13).
• Standard desktop environment.
• Custom compiled Gutsy kernel with automatic application prefetching implementation (patch).
• dir_indexes turned off for root partition.
• Prefetching was turned on.
• 3-aggregation was not used, prefetch always used last trace (side effect of some other change).

Test method:

• System boot time was measured by automatically running script when system boots (using ~/.kde/Autostart). The script recorded contents of /proc/uptime (first number is time since boot in seconds).
• Two setups were tested: with reordering and without reordering

With reordering setup:

• After each boot into tested system, system was manually booted from other partition and root partition of tested system was reordered based on split layouts produced by tested system using this script.
• Layout was split into 500-lines chunks as there was no such big contiguous space to hold whole prefetched area.

Without reordering setup:

• Image of tested system just before first reordering run was written back to partition and boot times were measure using automatic reboot script, as used in boot time tests.

Measurements repeatability:

• Each combination of parameters was tested 10 times.
• First run used boot traces from previous runs.

Test results

Notes:

1. During reordering tests, some of 500-lines chunks (from 0 to 3 max) failed to be reordered due to lack of free area big enough to hold it.
2. Reordering time for this setup was 14s - 20s.

IO ticks:

Conclusions

• Reordering can save quite significant amount of time (5.79s). Please note that this can be further improved as some chunks failed to be reordered.
• The speedup is caused almost completely by savings in IO ticks (4.47s difference in IO ticks while boot time difference is 5.79s).
• Disk with ~4.7 GB does not have large free areas for relocation, splitting prefetched area into chunks is necessary.
• Current chunk splitting technique is not good, it causes some chunks to fail. It also slows down reordering as reordering tool must be run several times. Layout tool should be improved to look for several areas with free space and fit prefetch data into these areas accordingly.
• Speed of reordering tool should be improved. 20s is rather the upper bound of time which can be used during shutdown for purpose of reordering. Consolidating reordering chunks should help, but also speedups in blocks moving would be useful.

Raw results are at: http://prefetch.googlecode.com/svn/trunk/results/reordering/testmachine-kl1/test-1-manual/

Test 2

The purpose of this test is to check what is a performance impact of automatic reordering files on disk.

Test description

Test machine: KL1

Test environment:

• Kubuntu Gutsy KL1 with updates as of 2007-06-10, moved to other partition (hda13).
• Standard desktop environment.
• Custom compiled Gutsy kernel with automatic application prefetching implementation (patch).
• dir_indexes turned off for root partition.
• Prefetching was turned on.
• 3-aggregation was not used, prefetch always used last trace (side effect of some other change).
• Results of manual reordering and no reordering for comparison were taken from test 1.

Test method:

• System boot time was measured by automatically running script when system boots (using ~/.kde/Autostart). The script recorded contents of /proc/uptime (first number is time since boot in seconds).
• One setup were tested: with reordering using automatic disk reordering.

Automatic reordering setup:

• During reboot files on disk were automatically reordered using prefetch-reorder init script.
• Layout was split into 2000-blocks chunks (default in /etc/default/prefetch).

Measurements repeatability:

• Each combination of parameters was tested 10 times.
• First run used boot traces from previous runs.

Test results

Notes:

1. Reordering time for this setup was 14s - 20s.
2. Copying files to chroot took longer.

Conclusions

• Automatic reordering is slightly worse than manual reordering (0.86s), but still 4.93s better than no reordering.
• Reordering time should be improved to be ready for widespread deployment.