From: Con Kolivas <conman@kolivas.net>
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@digeo.com>,
Paolo Ciarrocchi <ciarrocchi@linuxmail.org>,
Robinson Maureira Castillo <rmaureira@alumno.inacap.cl>,
Rodrigo Souza de Castro <rcastro@ime.usp.br>
Subject: [BENCHMARK] contest 0.50 results to date
Date: Sat, 5 Oct 2002 15:59:24 +1000 [thread overview]
Message-ID: <200210051559.38887.conman@kolivas.net> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are the updated contest (http://contest.kolivas.net) benchmarks with
version 0.50
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [3] 67.7 98 0 0 1.01
2.4.19-cc [3] 67.9 97 0 0 1.01
2.5.38 [3] 72.0 93 0 0 1.07
2.5.38-mm3 [2] 71.8 93 0 0 1.07
2.5.39 [2] 72.2 93 0 0 1.07
2.5.39-mm1 [2] 72.3 93 0 0 1.08
2.5.40 [1] 72.5 93 0 0 1.08
2.5.40-mm1 [1] 72.9 93 0 0 1.09
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [3] 106.5 59 112 43 1.59
2.4.19-cc [3] 105.0 59 110 42 1.56
2.5.38 [3] 89.5 74 34 28 1.33
2.5.38-mm3 [1] 86.0 78 29 25 1.28
2.5.39 [2] 91.2 73 36 28 1.36
2.5.39-mm1 [2] 92.0 73 37 29 1.37
2.5.40 [2] 82.8 80 25 23 1.23
2.5.40-mm1 [2] 86.9 77 30 25 1.29
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [3] 492.6 14 38 10 7.33
2.4.19-cc [3] 156.0 48 12 10 2.32
2.5.38 [1] 4000.0 1 500 1 59.55
2.5.38-mm3 [1] 303.5 25 23 11 4.52
2.5.39 [2] 423.9 18 30 11 6.31
2.5.39-mm1 [2] 550.7 14 44 12 8.20
2.5.40 [1] 315.7 25 22 10 4.70
2.5.40-mm1 [1] 326.2 24 23 11 4.86
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.19 [3] 100.0 72 33 3 1.49
2.4.19-cc [3] 92.7 76 146 21 1.38
2.5.38 [3] 107.3 70 34 3 1.60
2.5.38-mm3 [1] 100.3 72 27 2 1.49
2.5.39 [2] 103.1 72 31 3 1.53
2.5.39-mm1 [2] 103.3 72 32 3 1.54
2.5.40 [2] 102.5 72 31 3 1.53
2.5.40-mm1 [2] 107.7 68 29 2 1.60
Note the io_load value for 2.5.38 was an estimate as every time I tried to run
it it took too long and I stopped it (the longest I waited was 4000 seconds);
showing very clearly the write starves read problem.
Of most interest is the performance of 2.4.19 with the latest version of
compressed cache under mem_load (2.4.19-cc). Note that although the
performance is only slightly better timewise, the difference in actual work
done by the background load during that time is _enormous_. This demonstrates
most clearly the limitations in previous versions of contest.
Comments?
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9nn+8F6dfvkL3i1gRApHxAJ9CANpp1CA+chu+DxEghiNXgP0VjwCfdHsm
qf7yp7W6sBOnkNx/cmTLPQY=
=7oEd
-----END PGP SIGNATURE-----
next reply other threads:[~2002-10-05 5:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-05 5:59 Con Kolivas [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-10-05 18:28 [BENCHMARK] contest 0.50 results to date Paolo Ciarrocchi
2002-10-05 19:15 ` Andrew Morton
2002-10-05 20:56 ` Rodrigo Souza de Castro
2002-10-06 1:03 ` Con Kolivas
2002-10-05 19:28 Paolo Ciarrocchi
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=200210051559.38887.conman@kolivas.net \
--to=conman@kolivas.net \
--cc=akpm@digeo.com \
--cc=ciarrocchi@linuxmail.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rcastro@ime.usp.br \
--cc=rmaureira@alumno.inacap.cl \
/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.