Re: [BENCHMARK] 2.5.47-mm3 with contest

[Con Kolivas <conman@kolivas.net>]

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


>Andrew Morton wrote:
>>Con Kolivas wrote:
>>>Note the significant discrepancy between mm1 and mm3. This reminds me of
>>> what happened last time I enabled shared 3rd level pagetables - Andrew do
>>> you want me to do a set of numbers with this disabled?
>>
>>That certainly couldn't hurt.  But your tests are, in general, tesging
>>the IO scheduler.  And the IO scheduler has changed radically in each
>>of the recent -mm's.
>>
>>So testing with rbtree-iosched reverted would really be the only way
>>to draw comparisons on how the rest of the code is behaving.
>>-
>>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/
>
>Andrew there is, in fact a problem with the io scheduler in mm3 as far
>as I can see. Jens is away 'till Monday so he hasn't confirmed this yet.
>Basically if the device can't get through the entire queue within the
>read|write_expire timeout, they will start being submitted in fifo order
>slowing down the device more (probably) and contributing to the problem.
>It may be causing the bad numbers in contest. Here is a patch which
>relieves the problem for loads I am testing (bench.c, tiobench).
>
>Con, it would be nice if you could try this, if you value your disk,
>maybe you could wait for Jens to get back!

I gave it a quick run (with expire batch set to 16 to emulate fifo batch=16) 
and found only these different:

2.5.47-mm3ns is no shared 3rd level pagetables
2.5.47-mm3u is the same as 2.5.47-mm3ns but with your update

io_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.47-mm3ns [1]        121.8   60      5       7       1.71
2.5.47-mm3u [1]         161.1   47      9       9       2.26

read_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.47-mm3ns [2]        257.9   29      11      2       3.61
2.5.47-mm3u [1]         283.4   27      12      2       3.97

mem_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.47-mm3ns [1]        237.5   32      41      1       3.33
2.5.47-mm3u [1]         218.8   34      39      1       3.06

To me it does not appear to be the cause of the prolongation of kernel 
compilation time under io load in 2.5.47-mm3

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

iD8DBQE91ihYF6dfvkL3i1gRAqsnAKCAd0DkP1MDFe8DkNuTc/nl4XfYwQCgh4pR
FqhMIpEdOEFhQOnWx+wQNgE=
=shmO
-----END PGP SIGNATURE-----