ck9/7 v 2.4.19 performance with contest

[Con Kolivas <conman@kolivas.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've run some benchmarks with contest (http://contest.kolivas.net) and my 
latest patchset (http://kernel.kolivas.net) for public consumption. These are 
to explain why I've included compressed caching and removed the added vm 
work.

CAVEAT:

ck9 will only be advantageous over ck7 on uniprocessor machines with a normal 
or small amount of memory. If you have heaps of memory and almost never get 
into swap then the compressed caching will offer you no advantage. Worse yet, 
SMP machines no longer benefit from the added vm changes in ck7 - these were 
not compatible with compressed caching.

noload:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              67.7    98      0       0       1.01
2.4.19-ck7 [3]          73.8    96      0       0       1.10
2.4.19-ck9 [2]          68.8    97      0       0       1.02

You can see a slight difference here. ck7 and the 2.5 kernels show this 
unusual feature of taking longer to get started on a noload kernel compile 
after the memory and swap is all flushed. ck9 seems to have tamed this 
problem.

process_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              106.5   59      112     43      1.59
2.4.19-ck7 [3]          93.4    76      68      27      1.39
2.4.19-ck9 [2]          94.3    70      83      32      1.40

Minimal difference from ck7 in time taken, but during that time the background 
process has accomplished more work.

ctar_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [2]              106.5   70      1       8       1.59
2.4.19-ck7 [3]          142.3   57      2       10      2.12
2.4.19-ck9 [2]          110.5   71      1       9       1.65

ck7 exhibited quite aggressive work in the background load at the expense of 
the foreground process in tar creation. ck9 tames this a lot.

xtar_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [1]              132.4   55      2       9       1.97
2.4.19-ck7 [3]          238.3   33      5       11      3.55
2.4.19-ck9 [2]          138.6   58      2       11      2.06

Even more background work done by ck7 here; tamed by ck9.

io_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              492.6   14      38      10      7.33
2.4.19-ck7 [2]          174.6   41      8       8       2.60
2.4.19-ck9 [2]          140.6   49      5       5       2.09

Now under heavy file writing ck9 has relaxed even more than ck7 has.

read_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [2]              134.1   54      14      5       2.00
2.4.19-ck7 [2]          119.4   66      12      5       1.78
2.4.19-ck9 [2]          77.4    85      11      9       1.15

This overstates the advantage of ck9 over ck7 because the file read would be 
easy to compress. Nonetheless it is faster.

list_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [1]              89.8    77      1       20      1.34
2.4.19-ck7 [2]          104.0   70      1       21      1.55
2.4.19-ck9 [2]          85.2    79      1       22      1.27

Not sure why ck7 was slower than vanilla here, but ck9 improves on it. The 
resolution of loads performed cannot show less than 1 to show if ck7 or ck9 
did more work.

mem_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              100.0   72      33      3       1.49
2.4.19-cc [3]           92.7    76      146     21      1.38
2.4.19-ck7 [2]          116.0   69      35      3       1.73
2.4.19-ck9 [2]          78.3    88      31      8       1.17

This is the most interesting. I've included 2.4.19 with just cc added to show 
the difference. With cc heaps more work is done by the background load and 
only a modest improvement occurs in the kernel compilation time. ck9 on the 
other hand does about the same amount of background work as vanilla, but is 
significantly faster on kernel compilation time - a preferable balance I 
believe. Once again the advantage is overstated because the data would 
compress well but is present.

Cheers,
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9qsbVF6dfvkL3i1gRAuZ6AJwMDozAY7Bvujh8csCStlC5mWFUHwCfdSg0
2MNWYIRedppbyWh7P18uJN8=
=qWgv
-----END PGP SIGNATURE-----