From: Con Kolivas <kernel@kolivas.org>
To: linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: [BENCHMARK] 2.5.65 with contest
Date: Tue, 18 Mar 2003 20:27:25 +1100 [thread overview]
Message-ID: <200303182027.34652.kernel@kolivas.org> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are contest (http://contest.kolivas.org) benchmarks using the osdl
hardware (http://www.osdl.org) up to and including 2.5.65.
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 79 93.7 0.0 0.0 1.00
2.5.60 2 79 94.9 0.0 0.0 1.00
2.5.61 1 79 94.9 0.0 0.0 1.00
2.5.62 3 79 94.9 0.0 0.0 1.00
2.5.63 4 79 94.9 0.0 0.0 1.00
2.5.64 3 79 94.9 0.0 0.0 1.00
2.5.65 3 80 95.0 0.0 0.0 1.00
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 76 97.4 0.0 0.0 0.96
2.5.60 2 75 98.7 0.0 0.0 0.95
2.5.61 1 76 97.4 0.0 0.0 0.96
2.5.62 3 76 97.4 0.0 0.0 0.96
2.5.63 4 76 97.4 0.0 0.0 0.96
2.5.64 3 75 98.7 0.0 0.0 0.95
2.5.65 3 76 98.7 0.0 0.0 0.95
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 92 81.5 29.7 17.4 1.16
2.5.60 2 93 80.6 30.5 17.2 1.18
2.5.61 1 93 80.6 29.0 16.1 1.18
2.5.62 3 92 81.5 30.0 16.3 1.16
2.5.63 4 92 81.5 28.2 15.2 1.16
2.5.64 3 92 81.5 30.0 16.3 1.16
2.5.65 3 243 30.5 317.0 68.3 3.04
This is fair enough given process load is four processes and the kernel
compile is up to four (-j4)
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 98 80.6 2.0 5.1 1.24
2.5.60 2 99 78.8 1.0 4.0 1.25
2.5.61 2 100 79.0 1.0 4.0 1.27
2.5.62 3 99 79.8 1.0 4.0 1.25
2.5.63 3 99 79.8 1.0 4.0 1.25
2.5.64 3 100 79.0 0.0 0.0 1.27
2.5.65 3 108 72.2 0.0 0.0 1.35
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.20 1 130 59.2 2.0 4.6 1.67
2.5.59 3 102 74.5 1.0 3.9 1.29
2.5.60 2 101 76.2 1.0 5.0 1.28
2.5.61 2 102 75.5 1.0 4.9 1.29
2.5.62 3 103 73.8 1.0 3.9 1.30
2.5.63 3 102 74.5 1.0 3.9 1.29
2.5.64 3 103 73.8 1.0 3.9 1.30
2.5.65 3 106 71.7 1.0 3.8 1.32
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 152 50.0 34.1 13.1 1.92
2.5.60 2 139 54.7 29.0 12.1 1.76
2.5.61 2 143 52.4 32.9 13.3 1.81
2.5.62 2 205 36.6 51.7 15.0 2.59
2.5.63 5 217 35.0 56.7 15.1 2.75
2.5.64 3 229 33.2 58.8 14.8 2.90
2.5.65 3 411 19.0 137.5 20.4 5.14
More unused cpu time for the first time in a lot of kernels. Lots of work done
by io load in that time though.
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 89 84.3 11.2 5.6 1.13
2.5.60 2 90 83.3 10.8 5.5 1.14
2.5.61 2 91 82.4 11.1 5.5 1.15
2.5.62 2 96 78.1 15.7 8.2 1.22
2.5.63 4 95 78.9 15.3 8.3 1.20
2.5.64 3 100 75.0 18.4 9.0 1.27
2.5.65 3 164 47.6 71.7 26.2 2.05
Similar here but with not as great a rise in unused cpu time.
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 101 77.2 6.5 5.0 1.28
2.5.60 2 103 74.8 6.2 6.8 1.30
2.5.61 2 102 77.5 6.3 4.9 1.29
2.5.62 2 103 75.7 6.2 4.9 1.30
2.5.63 3 106 74.5 5.7 4.7 1.34
2.5.64 3 103 76.7 6.2 4.9 1.30
2.5.65 3 107 72.9 6.3 4.7 1.34
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 95 80.0 0.0 6.3 1.20
2.5.60 2 95 80.0 0.0 6.3 1.20
2.5.61 2 95 81.1 0.0 6.3 1.20
2.5.62 2 95 80.0 0.0 6.3 1.20
2.5.63 3 96 79.2 0.0 6.2 1.22
2.5.64 3 96 79.2 0.0 6.2 1.22
2.5.65 3 98 78.6 0.0 7.1 1.23
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 95 82.1 52.7 2.1 1.20
2.5.60 2 98 79.6 53.0 2.0 1.24
2.5.61 1 96 81.2 54.0 2.1 1.22
2.5.62 2 101 78.2 59.0 2.0 1.28
2.5.63 3 104 75.0 57.7 1.9 1.32
2.5.64 3 105 74.3 58.3 1.9 1.33
2.5.65 3 112 70.5 67.3 2.7 1.40
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 214 36.4 2.3 40.7 2.71
2.5.61 2 237 32.5 3.0 47.3 3.00
2.5.62 2 226 34.1 2.5 42.0 2.86
2.5.63 4 194 39.2 2.0 38.7 2.46
2.5.64 3 222 34.2 2.3 38.7 2.81
2.5.65 3 542 14.2 9.0 62.5 6.78
This one is interesting. More work done, more balance given to dbench, but no
more wasted cpu time. A pure balance change without wasted cycles. Since
dbench load is 16 processes this seems appropriate.
Massive changes all over the map. The scheduler tweaks have changed most of
the balance. I don't think contest is capable of showing the advantage of the
new tweaks designed to minimise things like audio stuttering. Perhaps Bill
Davidsen's trivial response benchmark is more suited.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+duZ/F6dfvkL3i1gRArkvAKCPq5x/1FlLBGUfdhNLLM8OIlfPXACeIxMK
SHrwEQMuOR92zcelAd5TvYU=
=zyrd
-----END PGP SIGNATURE-----
reply other threads:[~2003-03-18 9:16 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200303182027.34652.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.