Hi all,
as requested by GrandMasterLee (does he have a realname? ;) here goes
readlatency2 for 2.4.20aa1. Apply ontop of it.
Note: This patch rippes out the elevator-lowlatency hack.
ciao, Marc
On Thu, Dec 05, 2002 at 08:49:10PM +0100, Marc-Christian Petersen wrote:
> Hi all,
>
> as requested by GrandMasterLee (does he have a realname? ;) here goes
> readlatency2 for 2.4.20aa1. Apply ontop of it.
>
> Note: This patch rippes out the elevator-lowlatency hack.
how does it perform compared to elevator-lowlatency? I guess this is a
call for Con to run a pass on it.
Actually I still think the 32M queue on a 32M scsi machine during
contigous writes where the elevator basically doesn't matter is a
""bit"" overkill so I still like elevator-lowlatency somehow.
elevator-lowlatency could do something smarter than it currently does
though.
Andrea
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>On Thu, Dec 05, 2002 at 08:49:10PM +0100, Marc-Christian Petersen wrote:
>> Hi all,
>>
>> as requested by GrandMasterLee (does he have a realname? ;) here goes
>> readlatency2 for 2.4.20aa1. Apply ontop of it.
>>
>> Note: This patch rippes out the elevator-lowlatency hack.
>
>how does it perform compared to elevator-lowlatency? I guess this is a
>call for Con to run a pass on it.
>
>Actually I still think the 32M queue on a 32M scsi machine during
>contigous writes where the elevator basically doesn't matter is a
>""bit"" overkill so I still like elevator-lowlatency somehow.
>elevator-lowlatency could do something smarter than it currently does
>though.
Ask and ye shall receive. Here are contest results comparing vanilla 2.4.20,
aa1 and aa1 with rl2:
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 67.3 97 0 0 1.02
2.4.20aa1 [1] 68.0 97 0 0 1.03
2.4.20aa1rl2 [3] 67.4 97 0 0 1.02
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 65.7 99 0 0 0.99
2.4.20aa1 [1] 65.6 99 0 0 0.99
2.4.20aa1rl2 [3] 65.4 99 0 0 0.99
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 108.1 58 84 40 1.63
2.4.20aa1 [2] 224.6 28 342 70 3.39
2.4.20aa1rl2 [3] 223.1 29 337 70 3.37
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 207.2 32 2 46 3.13
2.4.20aa1 [3] 263.7 25 3 42 3.99
2.4.20aa1rl2 [3] 502.8 13 7 52 7.60
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 85.4 83 2 9 1.29
2.4.20aa1 [3] 86.3 82 3 10 1.30
2.4.20aa1rl2 [3] 97.1 78 3 10 1.47
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 107.6 64 2 8 1.63
2.4.20aa1 [1] 127.8 53 4 9 1.93
2.4.20aa1rl2 [3] 188.9 36 6 10 2.86
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 203.4 33 40 15 3.07
2.4.20aa1 [3] 238.3 27 46 15 3.60
2.4.20aa1rl2 [3] 302.5 22 63 16 4.57
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 120.3 56 24 16 1.82
2.4.20aa1 [3] 115.5 58 23 16 1.75
2.4.20aa1rl2 [3] 107.4 64 23 17 1.62
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 88.8 82 16 4 1.34
2.4.20aa1 [2] 97.8 71 18 6 1.48
2.4.20aa1rl2 [3] 130.1 54 26 6 1.97
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 75.7 88 0 8 1.14
2.4.20aa1 [2] 78.4 85 0 9 1.19
2.4.20aa1rl2 [3] 78.3 85 0 8 1.18
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 [5] 84.8 80 44 2 1.28
2.4.20aa1 [3] 179.7 37 59 1 2.72
2.4.20aa1rl2 [3] 180.2 37 51 1 2.72
Changes all over the place.
Cheers,
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE98HGsF6dfvkL3i1gRAnKJAJ9sW9tgN6Dzfu1s8/Ea8SUTBUf6egCfeyPY
3FAaG70qJYh7Z4PmZchFOYA=
=LCgH
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Con Kolivas wrote:
>> io_load:
>> Kernel [runs] Time CPU% Loads LCPU% Ratio
>> 2.4.20 [5] 203.4 33 40 15 3.07
>> 2.4.20aa1 [3] 238.3 27 46 15 3.60
>> 2.4.20aa1rl2 [3] 302.5 22 63 16 4.57
>
>Something must have gone wrong here. rl2 cannot be worse than
>2.4.20 in this test.
>
>Umm, quick sanity check:
>
>2.4.20-rl2 321.44 147% 96 24%
>2.4.20 361.70 130% 108 24%
>
>So only a 10% speedup, but certainly not a 50% slowdown. (That is
>on scsi).
>
>Maybe a patch preparation problem?
Dunno. This was just the patch mcp submitted which applies to aa1. Check the
top message in this thread. No doubt rl2 makes serious improvements to
vanilla 2.4.20 as a previous thread showed.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE98Iz6F6dfvkL3i1gRAgZ9AJ4zRB7dLsatDgsbTxg2SQfBnuNr/wCfV+xb
NdY2pNvyHPbFUTI5urAaTj8=
=vWBZ
-----END PGP SIGNATURE-----
Con Kolivas wrote:
>
> io_load:
> Kernel [runs] Time CPU% Loads LCPU% Ratio
> 2.4.20 [5] 203.4 33 40 15 3.07
> 2.4.20aa1 [3] 238.3 27 46 15 3.60
> 2.4.20aa1rl2 [3] 302.5 22 63 16 4.57
Something must have gone wrong here. rl2 cannot be worse than
2.4.20 in this test.
Umm, quick sanity check:
2.4.20-rl2 321.44 147% 96 24%
2.4.20 361.70 130% 108 24%
So only a 10% speedup, but certainly not a 50% slowdown. (That is
on scsi).
Maybe a patch preparation problem?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Con Kolivas wrote:
>> io_load:
>> Kernel [runs] Time CPU% Loads LCPU% Ratio
>> 2.4.20 [5] 203.4 33 40 15 3.07
>> 2.4.20aa1 [3] 238.3 27 46 15 3.60
>> 2.4.20aa1rl2 [3] 302.5 22 63 16 4.57
>
>Something must have gone wrong here. rl2 cannot be worse than
>2.4.20 in this test.
>
>Umm, quick sanity check:
>
>2.4.20-rl2 321.44 147% 96 24%
>2.4.20 361.70 130% 108 24%
>
>So only a 10% speedup, but certainly not a 50% slowdown. (That is
>on scsi).
>
>Maybe a patch preparation problem?
This seems to be more of a disagreement with -aa1 and -rl2 than -rl2 per se.
Just FYI here's a copy of the SMP results that were in the other thread
entitled "[PATCH] 2.4.20-rmap15a":
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 162.3 45 28 19 4.48
2.4.20 [5] 164.9 45 31 21 4.55
2.4.20-rl2 [3] 101.8 76 19 22 2.81
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 62.3 117 11 20 1.72
2.4.20 [5] 89.6 86 17 21 2.47
2.4.20-rl2 [3] 51.8 142 10 21 1.43
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE98JFqF6dfvkL3i1gRAgKLAJ49oxR+oe3k3UXrUycrsMeFVm8eYACdGmWU
mUuOA1uyw0xhPyQtcxvRyz0=
=OR9G
-----END PGP SIGNATURE-----