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 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.