* [BENCHMARK] 2.4.20-ck1 with contest
@ 2002-12-07 2:22 Con Kolivas
0 siblings, 0 replies; only message in thread
From: Con Kolivas @ 2002-12-07 2:22 UTC (permalink / raw)
To: linux kernel mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are contest (http://contest.kolivas.net) results for 2.4.20-ck1
(http://kernel.kolivas.net). This is the default ck1 patchset with the -aavm
and these include the optional low latency disk hack enabled:
Uniprocessor:
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 67.2 97 0 0 1.01
2.4.20 [5] 67.3 97 0 0 1.01
2.4.20-ck1 [5] 66.2 98 0 0 0.99
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 65.9 99 0 0 0.99
2.4.20 [5] 65.7 99 0 0 0.98
2.4.20-ck1 [5] 65.4 98 0 0 0.98
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 106.2 58 82 40 1.59
2.4.20 [5] 108.1 58 84 40 1.62
2.4.20-ck1 [5] 89.6 70 55 28 1.34
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 215.9 31 2 45 3.23
2.4.20 [5] 207.2 32 2 46 3.10
2.4.20-ck1 [5] 109.5 64 0 28 1.64
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 85.6 81 2 8 1.28
2.4.20 [5] 85.4 83 2 9 1.28
2.4.20-ck1 [5] 82.5 84 2 8 1.24
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 104.5 65 2 7 1.57
2.4.20 [5] 107.6 64 2 8 1.61
2.4.20-ck1 [5] 85.5 78 1 6 1.28
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 182.3 37 36 14 2.73
2.4.20 [5] 203.4 33 40 15 3.05
2.4.20-ck1 [5] 81.7 80 5 5 1.22
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 111.9 60 21 15 1.68
2.4.20 [5] 120.3 56 24 16 1.80
2.4.20-ck1 [4] 71.8 90 5 6 1.08
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 95.8 76 16 4 1.43
2.4.20 [5] 88.8 82 16 4 1.33
2.4.20-ck1 [4] 79.9 88 15 6 1.20
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 76.8 87 0 7 1.15
2.4.20 [5] 75.7 88 0 8 1.13
2.4.20-ck1 [4] 76.2 87 0 9 1.14
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 87.3 78 43 2 1.31
2.4.20 [5] 84.8 80 44 2 1.27
2.4.20-ck1 [4] 120.6 56 45 1 1.81
SMP:
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 38.0 183 0 0 1.05
2.4.20 [5] 36.9 189 0 0 1.02
2.4.20-ck1 [2] 37.0 186 0 0 1.02
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 35.9 193 0 0 0.99
2.4.20 [5] 35.8 194 0 0 0.99
2.4.20-ck1 [2] 35.5 194 0 0 0.98
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 49.8 140 20 57 1.38
2.4.20 [5] 51.0 138 20 59 1.41
2.4.20-ck1 [2] 46.3 146 19 52 1.28
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 159.4 45 0 40 4.40
2.4.20 [5] 144.8 49 0 38 4.00
2.4.20-ck1 [2] 72.9 96 0 19 2.01
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 43.7 165 1 10 1.21
2.4.20 [5] 43.1 169 1 11 1.19
2.4.20-ck1 [2] 43.8 162 0 8 1.21
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 49.2 144 1 10 1.36
2.4.20 [5] 63.5 114 1 12 1.75
2.4.20-ck1 [2] 44.4 158 0 7 1.23
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-ck1 [2] 50.4 140 5 11 1.39
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-ck1 [2] 42.7 163 3 11 1.18
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 60.2 123 9 7 1.66
2.4.20 [5] 51.0 143 7 7 1.41
2.4.20-ck1 [2] 41.7 173 5 8 1.15
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 40.3 174 0 8 1.11
2.4.20 [5] 40.4 175 0 8 1.12
2.4.20-ck1 [2] 39.3 178 0 7 1.09
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [5] 53.7 133 36 3 1.48
2.4.20 [5] 52.0 139 37 3 1.44
2.4.20-ck1 [2] 76.6 93 36 2 2.12
Points to note:
It is more than just coincidence that the results of -ck are good with contest
since responsiveness is the main aim in my patchset and contest is my main
testing method. I resisted posting these results because they look rigged,
but many people have asked for them
A lot of these benchmarks occur in the setting of competing writes/reads from
disk and the disk hack will be responsible for most of the low scores. This
disk hack is not recommended for use in situations where throughput is
important (eg servers). The lower throughput is not noticeable most of the
time on a desktop, but the lack of pauses and increased responsiveness is
noticed. It does cause a noticeable slowdown on devices with poor caching of
their own (eg zip disks).
I am looking into the lower mem_load performance. This appears to have
surfaced with the resync to 2.4.20. Most of the vm changes to 2.4.20-ck1 were
similar to 2.4.19-ck* but were the latest patches from -aa's tree. I have
been investigating moving to -rmap for the default tree as it matures but
it's performance, while improving, is not quite as good on contest just yet.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE98VuCF6dfvkL3i1gRAobVAJ4+RFkunqKRLRLUewSu6Q++ZmJ4ngCcCIph
/enT8LVfj7V26gludYLSQyQ=
=y9uF
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2002-12-07 2:13 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-07 2:22 [BENCHMARK] 2.4.20-ck1 with contest Con Kolivas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox