-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are some io_load contest benchmarks with 2.4.20 with the read latency2
patch applied and varying the max bomb segments from 1-6 (SMP used to save
time!)
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 164.9 45 31 21 4.55
2420rl2b1 [5] 93.5 81 18 22 2.58
2420rl2b2 [5] 88.2 87 16 22 2.44
2420rl2b4 [5] 87.8 84 17 22 2.42
2420rl2b6 [5] 100.3 77 19 22 2.77
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 89.6 86 17 21 2.47
2420rl2b1 [3] 48.1 156 9 21 1.33
2420rl2b2 [3] 50.0 149 9 21 1.38
2420rl2b4 [5] 51.9 141 10 21 1.43
2420rl2b6 [5] 52.1 142 9 20 1.44
There seems to be a limit to the benefit of decreasing max bomb segments. It
does not seem to have a significant effect on io load on another hard disk
(although read latency2 is overall much better than vanilla).
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE98YUEF6dfvkL3i1gRAn4kAJ4x414sM3G+8fVrXv2P0huRhNKicgCgqFyo
kCXIKMVtO/Zp+tM92qlUz4s=
=HOKs
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Here are some io_load contest benchmarks with 2.4.20 with the read latency2
>patch applied and varying the max bomb segments from 1-6 (SMP used to save
>time!)
>
>io_load:
>Kernel [runs] Time CPU% Loads LCPU% Ratio
>2.4.20 [5] 164.9 45 31 21 4.55
>2420rl2b1 [5] 93.5 81 18 22 2.58
>2420rl2b2 [5] 88.2 87 16 22 2.44
>2420rl2b4 [5] 87.8 84 17 22 2.42
>2420rl2b6 [5] 100.3 77 19 22 2.77
>
>io_other:
>Kernel [runs] Time CPU% Loads LCPU% Ratio
>2.4.20 [5] 89.6 86 17 21 2.47
>2420rl2b1 [3] 48.1 156 9 21 1.33
>2420rl2b2 [3] 50.0 149 9 21 1.38
>2420rl2b4 [5] 51.9 141 10 21 1.43
>2420rl2b6 [5] 52.1 142 9 20 1.44
>
>There seems to be a limit to the benefit of decreasing max bomb segments. It
>does not seem to have a significant effect on io load on another hard disk
>(although read latency2 is overall much better than vanilla).
>
>Con
Further testing with changing values of read and write latencies (with fixed
max_bomb to 4) and the read latency 2 patch in place shows no significant
change to these figures over a wide range of numbers. This was not the case
when I ran contest with different read latency values on the vanilla kernel
(and found -r 512 to be a reasonable compromise according to Jens). Is there
some other advantage to be gained by say increasing these numbers? (since
contest results don't change with higher numbers either)
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE98ffKF6dfvkL3i1gRAo01AJ0Zvs0x80vGF1hUillnIL4y+f6xRQCfZyni
YkNWPMORdfjRHfG5/6NxV4M=
=g1ht
-----END PGP SIGNATURE-----
In article <[email protected]>,
Con Kolivas <[email protected]> wrote:
>Here are some io_load contest benchmarks with 2.4.20 with the read latency2
>patch applied
Where is the rl2 patch for 2.4.20-vanilla ?
Mike.
--
They all laughed when I said I wanted to build a joke-telling machine.
Well, I showed them! Nobody's laughing *now*! -- [email protected]
On Tuesday 10 December 2002 11:50, Miquel van Smoorenburg wrote:
Hi Miquel,
> >Here are some io_load contest benchmarks with 2.4.20 with the read
> > latency2 patch applied
> Where is the rl2 patch for 2.4.20-vanilla ?
here.
ciao, Marc