Department of Computer Science
University of São Paulo
São Paulo, Brazil
Linux Kernel Compilation is widely used to measure VM performance and owns unique characteristics. Among them, a high CPU and VM usage, mainly when forking its build (make -j). It's very important for our Compressed Cache development to compile the Linux Kernel since we will be able to check if our CPU overhead (mostly when de/compressed pages) will impact over scenarios like that. Of course we will also be able to check out if a kernel compilation would make better use of the reserved space for our current Compressed Cache and if we could improve the code and increase (maybe even more) overall system performance when running such kind of applications.
Note: An analysis of the bad performance and its possible causes is showed below.
As you may notice in the graphics above, the CPU usage for compressed cache, mainly for larger sizes, is much lower than vanilla case. It seems we are sleeping much more than vanilla, what seems, at the first sight, preposterous since we may be saving up disk accesses and therefore should be sleeping less.
I've profiled the code for 24 MiB compressed cache and "make -j 4" case (profile here). There's no clear cause noticeable in that profile. Anyway, since we have a huge number of decompressions, my guess is that we are having troubles allocating the huge number of pages that need to be allocated to store the decompressed fragments. Given that we are under constantly memory pressure in uncompressed cache, we are probably sleeping too many times to be able to allocate the necessary pages.
Page last updated on "Tue Jun 4 06:52:09 2002"
Send feedback to Rodrigo S. de Castro
<rcastro@lists.sourceforge.net>