The final parameter is the cleaning threshold. This value defines the percentage of buffers that have to be full before a cleaning operation is started. To study the influence this parameter has, we have set the cache size to 256Mbytes and we have varied the threshold from 1% to 70%. The results obtained by all the benchmarks are presented in Figure 6. The performance of simulator x5 is also not included in this graph for the same reason as in the previous subsection.
Figure 6:
Influence of the cleaning threshold on the application performance.
We can observe that this parameter cannot be too small. In this case, many small write operations are performed and the seek and search actions become an important overhead in these write operations. When the threshold grows, the performance of the applications tends to increase as the disk latency becomes less important.
For very large values, the behavior of the system depends on whether the benchmark is a mono or multi-process one. In mono-process benchmarks, when the cache is being cleaned (synchronous cleaning), no other process accesses the disk and the benefits of large writes continue to be the a good issue. On the other hand, in multi-process benchmarks, while a process is cleaning the cache, another may want to swap in or out a page. If the cleaning operation is too long, the read/write operation has to wait for a long time and the performance of this process is also affected in a negative way.
The benchmark sort x6 has a very unpredictable behavior. It does not follow any clear pattern. The reason behind this behavior is the large amount of I/O it performs. If it tries to write while the system is cleaning the cache, the performance is greatly affected. There is no way to avoid these collisions, but still the results are good enough.
It seems that the best value for this threshold is between 10% and 20%.