4.2 Benchmark Description

 

To measure the performance of this proposal, we need to see the effect it has on a set of benchmarks. Before getting into a detailed description of the benchmarks, we would like to describe the three characteristics a benchmark can have that may have a higher effect on the behavior of the proposed system.

Concurrency.

It is important to see that the number of processes in the benchmark will affect the behavior of the system. If only one process is running in the system, the application that is swapping out pages will not have to wait for another application that may have locked some of the resources it needs. No other application will try to swap in/out pages.

I/O.

Another benchmark parameter that will affect the system is the amount of file-system I/O performed by the benchmark. This I/O may conflict with the one performed by the paging system because both are done in the same disk (although in different partitions).

Compression ratio.

Finally, the compression ratio may affect the system in two ways. First, the better pages compress, the larger the final size of the swap area will be. Second, if pages have a good compression ratio, the number of pages that can be kept in the cache will be higher. Thus the number of disk accesses should be lower than with bad compression ratios.

Once described the most important characteristics, we will describe the benchmarks used.

• fft. It executes a fast Fourier transformation with a 2048x2048 matrix. The values of the elements in the matrix are set randomly.
• fft x10. This benchmark is very similar to the previous one but 10 ffts are executed concurrently and the size of the matrixes is decreased to 512x512 elements.
• sort. In this benchmark, we perform an in-memory sort of a text file. The input file is build by appending the /usr/dict/word file many times and then unsorting it as much as possible.
• sort x6. In this benchmark 6 sorts are executed concurrently. The file to be sorted is built as the previous one but 5 times smaller to limit the execution time of the benchmark.
• simulator. A simulator of a network of disks currently being used in our research group. It is an event-based simulator that uses large amounts of memory. This memory compresses very well as many of the events in the queues have similar information. Furthermore, the memory library used, does not free the allocated memory after a free, the library keeps the memory block in a hash queue for further use. This "freed" memory is also easy to compress. Although the compression ratio of this application seems to be unrealistic, there are other applications in a typical Unix system that achieve compression ratios better than 10% such as awk [7].
• simulator x5. Five concurrent executions of the simulator but with a smaller input.
• xanim. A visualization of a video file in avi format. This video is dithered using the Floyd-Steinberg algorithm. This means that the file has to be decompressed in memory to do the dithering before it is visualized. This benchmark has been run under the X-Windows system as it needed to perform graphic I/O.
• xanim x4. Four concurrent executions of the previous xanim benchmark.

Table 1 summarizes the characteristics of each benchmark according to the parameters described in the first part of this subsection.

 
Table 1:   Benchmark characteristics.