From: Con Kolivas <conman@kolivas.net>
To: linux kernel mailing list <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@digeo.com>, Nick Piggin <piggin@cyberone.com.au>
Subject: [BENCHMARK] 2.5.59-mm6 with contest
Date: Fri, 31 Jan 2003 16:52:14 +1100 [thread overview]
Message-ID: <200301311652.47715.conman@kolivas.net> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are contest (http://contest.kolivas.net) benchmark results with the osdl
hardware (http://www.osdl.org) for 2.5.59-mm6 (reconfigured hardware again to
get most useful results with contest). These results have been checked for
accuracy, repeatability and asterisks have been placed next to statistically
significant differences.
I do believe these show that sequential reads are indeed scheduled before
writes with this kernel. The question is, how long should they be scheduled
for?
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 79 94.9 0 0.0 1.00
2.5.59-mm6 1 78 96.2 0 0.0 1.00
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 76 98.7 0 0.0 0.96
2.5.59-mm6 1 76 97.4 0 0.0 0.97
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 92 81.5 28 16.3 1.16
2.5.59-mm6 1 92 81.5 25 15.2 1.18
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 98 80.6 2 5.1 1.24*
2.5.59-mm6 3 112 70.5 2 4.5 1.44*
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 101 75.2 1 4.0 1.28*
2.5.59-mm6 3 115 66.1 1 4.3 1.47*
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 153 50.3 8 13.7 1.94*
2.5.59-mm6 3 106 70.8 4 9.4 1.36*
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 102 76.5 5 4.9 1.29*
2.5.59-mm6 3 733 10.8 56 6.3 9.40*
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 95 80.0 0 6.3 1.20*
2.5.59-mm6 3 97 79.4 0 6.2 1.24*
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 97 80.4 56 2.1 1.23
2.5.59-mm6 3 94 83.0 50 2.1 1.21
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 126 60.3 3 22.2 1.59
2.5.59-mm6 3 122 61.5 3 25.4 1.56
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.59 3 89 84.3 2 5.5 1.13
2.5.59-mm6 2 90 83.3 2 6.7 1.15
io_load result is excellent showing the continuous write is delaying kernel
compilation by much less. read_load tells the rest of the story though.
read_load repeatedly reads a 256Mb file (the size of physical ram in the test
machine)
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+Og8RF6dfvkL3i1gRAvLaAJ96HIePSeQ3TasNr8o19fzJGOyUUwCfTM4w
UKY8C9r2/2F5e4rrv9yOx7g=
=y8wz
-----END PGP SIGNATURE-----
next reply other threads:[~2003-01-31 5:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-31 5:52 Con Kolivas [this message]
2003-01-31 7:38 ` [BENCHMARK] 2.5.59-mm6 with contest Andrew Morton
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=200301311652.47715.conman@kolivas.net \
--to=conman@kolivas.net \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox