-----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-----
-
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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:17 EST