Department of Computer Science
University of São Paulo
São Paulo, Brazil
Dbench is an IO intensive benchmark widely used to measure VM and FS performance. We'd like to check out how well our current Compressed Cache code can perform under such conditions. A test like this can help us see scenarios where our code does not behave very well, pointing out parameters to be used for our automcatic adaptivity or even come up with ideas to improve our implementation, if necessary.
An analysis of the performance and their causes is showed below.
Dbench performs intensive IO with a number of concurrent processes. Therefore, page and buffer cache are very important for its performance.
Recall that we only compress dirty anonymous pages. And also that we reserve (so far) the fixed size cache at the boot time, making this amount of memory (from 4 to 24 MiB) unavailable for other use than store compressed dirty anonymous pages.
Few pages were compressed in all cases and even though we might have avoided disk paging in some moment, the space reserved for Compressed Cache resulted in a smaller page and buffer cache (as seen in vmstat).
Like noticed in Linux Kernel compilation case, we may improve Compressed Cache peformance by compressing pages from page cache and even buffers. But it may not be worth due to the overhead. Anyway, something to think about, since it will help a lot applications and scenarios where IO is heavily used.
The adaptivity parameter for this kind of scenario will depend on the previous item. If we keep compressing "only" the dirty anonymous pages, it will be essential to measure IO activity in the overall performance. In the case that's the majority of the system activities and the compressed cache is not helping avoiding much disk paging (like dbench case), we should swap out the compressed pages. That will allow us to shrink the compressed cache, giving away this memory to the buffer and page caches, hopefully improving system performance.
Page last updated on "Tue Jun 4 06:56:33 2002"
Send feedback to Rodrigo S. de Castro
<rcastro@lists.sourceforge.net>