2.5.59-mm8 with contest

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

Here are contest benchmarks using osdl hardware. More resolution has been 
added to the io loads and read load (thanks Aggelos)

no_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       79      94.9    0.0     0.0     1.00
2.5.59-mm7      5       78      96.2    0.0     0.0     1.00
2.5.59-mm8      3       79      93.7    0.0     0.0     1.00
cacherun:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       76      98.7    0.0     0.0     0.96
2.5.59-mm7      5       75      98.7    0.0     0.0     0.96
2.5.59-mm8      3       76      97.4    0.0     0.0     0.96
process_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       92      81.5    28.3    16.3    1.16
2.5.59-mm7      3       95      77.9    33.7    18.9    1.22
2.5.59-mm8      3       195     37.9    205.3   60.5    2.47

seems the scheduler changes have changed the balance of what work is done with 
this process load. No cpu cycles are wasted so it is not necessarily a bad 
result.


ctar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       98      80.6    2.0     5.1     1.24
2.5.59-mm7      5       96      80.2    1.4     3.4     1.23
2.5.59-mm8      3       99      78.8    2.0     5.1     1.25
xtar_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       101     75.2    1.0     4.0     1.28
2.5.59-mm7      5       96      79.2    0.8     3.3     1.23
2.5.59-mm8      3       100     77.0    1.0     4.0     1.27
io_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       154     48.7    32.6    12.3    1.95
2.5.59-mm7      3       112     67.0    15.9    7.1     1.44
2.5.59-mm8      3       152     50.0    35.4    13.1    1.92

This seems to be creeping up to the same as 2.5.59


read_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       101     77.2    6.3     5.0     1.28
2.5.59-mm7      3       94      80.9    2.8     2.1     1.21
2.5.59-mm8      3       93      81.7    2.8     2.2     1.18
list_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       95      80.0    0.0     6.3     1.20
2.5.59-mm7      4       94      80.9    0.0     6.4     1.21
2.5.59-mm8      3       98      78.6    0.0     6.1     1.24
mem_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       97      80.4    56.7    2.1     1.23
2.5.59-mm7      4       92      82.6    45.5    1.4     1.18
2.5.59-mm8      3       97      80.4    53.3    2.1     1.23
dbench_load:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       126     60.3    3.3     22.2    1.59
2.5.59-mm7      4       121     62.0    2.8     24.8    1.55
2.5.59-mm8      3       212     35.8    11.0    47.2    2.68

and this seems to be taking significantly longer


io_other:
Kernel     [runs]       Time    CPU%    Loads   LCPU%   Ratio
2.5.59          3       89      84.3    11.2    5.4     1.13
2.5.59-mm7      3       92      81.5    12.6    6.5     1.18
2.5.59-mm8      3       115     67.8    35.2    18.3    1.46

And this load which normally changes little has significantly different 
results.

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE+QPPNF6dfvkL3i1gRAjh9AJ0VrUQBD9SbKX8jQNOtnYlwv0Ud2QCfdU+Q
k6hvNs0RWwIBc4PLSrc5eSo=
=ujgV
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/