Re: [BENCHMARK] 2.5.47-mm3 with contest

Con Kolivas
2002-11-16T11:06:44Z

>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