Next: 4.3 Performance Results
Up: 4 Experimental Evaluation
Previous: 4.1 Methodology
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.
Next: 4.3 Performance Results
Up: 4 Experimental Evaluation
Previous: 4.1 Methodology
Toni Cortes
Tue Apr 27 17:43:22 MET DST 1999