From: Con Kolivas <conman@kolivas.net>
To: linux kernel mailing list <linux-kernel@vger.kernel.org>
Cc: Paolo Ciarrocchi <ciarrocchi@linuxmail.org>,
Andrew Morton <akpm@digeo.com>
Subject: [BENCHMARK] vm swappiness with contest
Date: Fri, 27 Dec 2002 16:46:00 +1100 [thread overview]
Message-ID: <200212271646.01487.conman@kolivas.net> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is a family of contest benchmarks using the osdl hardware in uniprocessor
mode on 2.5.53-mm1 while varying vm swappiness. s020 is vm swappiness=20 and
so on:
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 71.1 95 0 0 1.07
s020 [5] 71.9 95 0 0 1.08
s040 [5] 71.7 95 0 0 1.07
s060 [5] 71.3 96 0 0 1.07
s080 [5] 71.3 95 0 0 1.07
s100 [5] 71.6 95 0 0 1.07
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 68.4 99 0 0 1.02
s020 [5] 68.8 99 0 0 1.03
s040 [5] 68.7 99 0 0 1.03
s060 [5] 68.6 99 0 0 1.03
s080 [5] 68.5 99 0 0 1.03
s100 [5] 68.7 99 0 0 1.03
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 119.0 57 49 41 1.78
s020 [5] 119.4 57 49 41 1.79
s040 [5] 118.6 57 48 41 1.78
s060 [5] 117.6 57 47 41 1.76
s080 [5] 119.5 57 49 41 1.79
s100 [5] 118.4 58 48 40 1.77
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 191.6 41 1 43 2.87
s020 [5] 195.5 40 1 44 2.93
s040 [5] 197.9 41 1 43 2.96
s060 [5] 331.4 32 0 23 4.96
s080 [5] 439.4 24 0 10 6.58
s100 [5] 883.6 13 1 9 13.24
The first of the massive effect of changing this value. A recurring theme is
large file writes with a swappy kernel seems to waste time swapping data
because of the IO data. Obviously none of these IO loads use the o_direct
option.
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 113.4 81 3 10 1.70
s020 [5] 103.3 80 2 9 1.55
s040 [5] 110.0 79 3 9 1.65
s060 [5] 103.0 80 3 9 1.54
s080 [5] 104.4 80 2 8 1.56
s100 [5] 100.2 80 2 8 1.50
Slightly slower with an unswappy kernel
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 139.2 65 3 8 2.09
s020 [5] 128.7 70 2 7 1.93
s040 [5] 152.8 59 3 7 2.29
s060 [5] 137.0 64 2 6 2.05
s080 [5] 124.6 66 2 6 1.87
s100 [5] 127.6 66 2 6 1.91
Up and down, no firm pattern
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 121.8 63 21 17 1.82
s020 [5] 125.9 61 22 17 1.89
s040 [5] 130.1 59 22 17 1.95
s080 [5] 174.6 47 27 15 2.62
s100 [5] 208.1 42 25 11 3.12
Increase the swappiness, increase the kernel compile time as dbench_load does
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 103.6 73 18 17 1.55
s020 [5] 135.4 62 25 18 2.03
s040 [5] 157.7 57 28 18 2.36
s060 [5] 188.1 48 32 16 2.82
s080 [5] 246.2 37 38 15 3.69
s100 [5] 378.8 24 45 11 5.67
Another massive change.
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 89.7 80 15 7 1.34
s020 [5] 91.1 79 13 6 1.36
s040 [5] 90.6 79 12 6 1.36
s060 [5] 90.3 79 12 6 1.35
s080 [5] 90.3 79 12 6 1.35
s100 [5] 92.2 78 10 5 1.38
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 81.8 85 0 9 1.23
s020 [5] 81.9 85 0 9 1.23
s040 [5] 82.0 85 0 9 1.23
s060 [5] 82.2 85 0 8 1.23
s080 [5] 82.7 85 0 8 1.24
s100 [5] 83.1 85 0 8 1.24
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
s000 [3] 233.2 32 65 1 3.49
s020 [5] 172.3 42 50 1 2.58
s040 [5] 163.8 46 44 1 2.45
s060 [5] 192.2 39 38 1 2.88
s080 [5] 186.4 42 37 0 2.79
s100 [5] 128.2 57 37 1 1.92
Here it seems only the extreme values make a difference. Un unswappy kernel
makes it slow down significantly, whereas a swappy kernel speeds it up
significantly.
Paolo if I was to choose a number from these values I'd suggest lower than 60
rather than higher, BUT that is because the io load effects become a real
problem when the kernel is swappy - don't _really_ know what this means for
the rest of the time. Maybe in the 40-50 range. There seems to be a knee
(bend) in the curve (most noticable in dbench_load) rather than the curves
being linear. That knee I believe simply shows the way the algorithm for
swappiness basically works. I might throw a 50 at the machine as well to see
what that does.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+C+kYF6dfvkL3i1gRAt2HAJ9UJFKO2i5K6LW/7WU+cJ1TBOtlEQCeISK7
7ecGaUImIiJvC1Bz649vmH8=
=UI1t
-----END PGP SIGNATURE-----
next reply other threads:[~2002-12-27 5:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-27 5:46 Con Kolivas [this message]
2002-12-27 10:00 ` [BENCHMARK] vm swappiness with contest Con Kolivas
2002-12-28 6:16 ` Con Kolivas
2002-12-28 6:26 ` Andrew Morton
2002-12-28 8:05 ` Linus Torvalds
2002-12-31 5:58 ` Con Kolivas
2002-12-31 6:08 ` Andrew Morton
2002-12-31 6:24 ` Con Kolivas
2002-12-31 6:37 ` Andrew Morton
2002-12-31 6:57 ` Con Kolivas
2002-12-31 7:08 ` Andrew Morton
2002-12-31 7:20 ` Con Kolivas
-- strict thread matches above, loose matches on Subject: below --
2002-12-27 13:13 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=200212271646.01487.conman@kolivas.net \
--to=conman@kolivas.net \
--cc=akpm@digeo.com \
--cc=ciarrocchi@linuxmail.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.