2.5.70-mm2 with contest

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

no_load:

Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              1   80      93.8    0.0     0.0     1.00
2.5.69-mm3          1   79      94.9    0.0     0.0     1.00
2.5.69-mm5          1   79      94.9    0.0     0.0     1.00
2.5.69-mm6          1   78      96.2    0.0     0.0     1.00
2.5.70              1   79      94.9    0.0     0.0     1.00
2.5.70-mm2          1   78      94.9    0.0     0.0     1.00
cacherun:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              1   76      98.7    0.0     0.0     0.95
2.5.69-mm3          1   76      98.7    0.0     0.0     0.96
2.5.69-mm5          1   76      98.7    0.0     0.0     0.96
2.5.69-mm6          1   76      98.7    0.0     0.0     0.97
2.5.70              1   75      98.7    0.0     0.0     0.95
2.5.70-mm2          1   75      98.7    0.0     0.0     0.96
process_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              2   181     41.4    196.5   58.0    2.26
2.5.69-mm3          2   176     42.0    183.0   56.2    2.23
2.5.69-mm5          2   176     42.6    182.5   55.7    2.23
2.5.69-mm6          2   176     42.0    184.5   55.7    2.26
2.5.70              2   109     67.9    63.5    28.4    1.38
2.5.70-mm2          2   108     68.5    65.5    28.7    1.38

Same changes put into 2.5.70 are evident in mm2

ctar_load:

Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              3   103     75.7    0.0     0.0     1.29
2.5.69-mm3          3   126     63.5    1.0     4.8     1.59
2.5.69-mm5          3   114     70.2    1.0     5.3     1.44
2.5.69-mm6          3   112     70.5    1.0     5.4     1.44
2.5.70              3   103     75.7    0.0     0.0     1.30
2.5.70-mm2          3   118     66.9    1.0     5.1     1.51

probably not statistically significant

xtar_load:

Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              3   106     72.6    1.0     3.7     1.32
2.5.69-mm3          3   111     69.4    1.7     4.5     1.41
2.5.69-mm5          3   102     75.5    1.0     4.9     1.29
2.5.69-mm6          3   107     72.0    1.3     4.7     1.37
2.5.70              3   106     72.6    1.0     3.8     1.34
2.5.70-mm2          3   123     61.8    2.0     4.8     1.58

small rise in time with multiple small file extraction

io_load:

Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              4   343     22.7    120.5   19.8    4.29
2.5.69-mm3          4   319     24.5    105.3   18.1    4.04
2.5.69-mm5          4   137     56.9    49.6    19.0    1.73
2.5.69-mm6          4   150     52.0    53.4    18.7    1.92
2.5.70              5   326     21.5    112.9   18.7    4.13
2.5.70-mm2          4   115     67.0    42.0    19.1    1.47

large drop in time with one large file write

io_other:

Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              2   127     61.4    55.5    24.4    1.59
2.5.69-mm3          2   133     58.6    47.1    18.7    1.68
2.5.69-mm5          2   115     67.8    46.4    20.7    1.46
2.5.69-mm6          2   120     65.0    50.9    21.5    1.54
2.5.70              2   122     63.9    53.8    22.1    1.54
2.5.70-mm2          2   113     68.1    46.2    20.4    1.45
read_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              2   104     75.0    6.3     4.8     1.30
2.5.69-mm3          2   113     69.9    9.1     6.1     1.43
2.5.69-mm5          2   113     69.9    9.0     6.2     1.43
2.5.69-mm6          2   115     68.7    9.1     6.1     1.47
2.5.70              2   104     75.0    6.3     4.8     1.32
2.5.70-mm2          2   106     73.6    8.2     5.7     1.36

seems to correlate with .70 changes

list_load:

Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              2   95      81.1    0.0     5.3     1.19
2.5.69-mm3          2   95      81.1    0.0     7.4     1.20
2.5.69-mm5          2   96      80.2    0.0     7.3     1.22
2.5.69-mm6          2   96      80.2    0.0     7.3     1.23
2.5.70              2   96      80.2    0.0     7.3     1.22
2.5.70-mm2          2   94      81.9    0.0     7.4     1.21
mem_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              2   98      79.6    60.5    2.0     1.23
2.5.69-mm3          2   135     59.3    77.0    2.2     1.71
2.5.69-mm5          2   99      79.8    53.0    2.0     1.25
2.5.69-mm6          2   100     79.0    60.0    2.0     1.28
2.5.70              2   97      80.4    53.5    2.1     1.23
2.5.70-mm2          2   99      78.8    54.5    2.0     1.27
dbench_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.69              4   374     20.3    5.0     48.1    4.67
2.5.69-mm3          4   653     11.6    6.2     34.0    8.27
2.5.69-mm5          4   316     24.1    4.0     44.6    4.00
2.5.69-mm6          4   386     19.9    5.2     48.4    4.95
2.5.70              5   321     22.1    4.0     44.5    4.06
2.5.70-mm2          4   305     24.9    4.8     55.4    3.91

I tried getting runs on 2.5.69-mm9 and 2.5.70-mm1 but ran into BUGs that have been reported before on lkml.

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

iD8DBQE+28p4F6dfvkL3i1gRAvsgAJ4mf8syPqOXkNt+tuNaoFgdMQZ8KQCdH/Er wWRW9HrkWqpd9UTIeR/Lzz4=
=ly6r
-----END PGP SIGNATURE-----

We're hitting nearly 90% CPU here. That is really excellent.

mm3 should be OK. After several days more testing I have not found any bugs in mm3's ext3 which are not already in 2.5.70 ;)

Yes, the contest results have held up nicely after those big changes to AS which is good.

It will be interesting to see what happens if we set the ext3 journal write paths as PF_SYNCWRITE. I'll try some tests a bit later today.

* Andrew Morton <[email protected]>:

I've hit assertion() /fs/jbd/transaction.c:1115 several times. Can't tell anything else, as immediately after this keyboard gets locked, X still reacts on _mouse_ (copy/paste thing) , but probably after hitting disk/filesystem every application locks. for example cpu load meter which open-read /proc gets frozen right away.
/var/log/messages doesn't tell a thing. Seems random.

kernel 2.5.70-mm3.

   Psi -- <http://www.iki.fi/pasi.savolainen>

OK.

Longer-term it would be best to lose the PF_SYNCWRITE thing and to just mark the BIOs as synchronous prior to submitting them. It's a matter of transferring the info in writeback_control.sync_mode at the pagecache/BIO
boundary: mpage_bio_submit(), __block_write_full_page->submit_bh(), etc.

But we can worry about that later, once it is established that the synchronous write detection is sufficiently useful.

Yeah that is better. Would be no problem for AS.