From: Con Kolivas <conman@kolivas.net>
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@digeo.com>
Subject: [BENCHMARK] Greater resolution mem_load from contest
Date: Sat, 21 Sep 2002 00:12:49 +1000 [thread overview]
Message-ID: <1032531169.3d8b2ce16fb26@kolivas.net> (raw)
Here are some results you may find informative.
I adjusted the mem_load module of contest (http://contest.kolivas.net) to vary
the memory load from 10 to 110% in increments of 10% and performed the test on
the following kernels.
What I found is that performance regardless of the kernel was constant (for that
kernel) up to 70% (presumably the critical number for my 256Mb machine).
What happened beyond this point, however, was quite different between kernels.
Here are the results:
Kernel: 2.4.19 rmap14b 2.5.36 2.5.36-mm1
Mem%
60 76.34 76.98 66.62 69.12
70 76.22 77.14 67.21 67.28
80 79.20 80.14 68.24 70.29
90 82.59 115.51 148.63 92.96
100 84.21 108.61 107.54 95.50
110 92.49 114.51 132.45 95.32
As you can see, in absoute performance the 2.5 kernels at low mem loads are better.
rmap14b (2.4.19-rmap14b) performance is identical to vanilla till 80%.
Beyond this point it starts to deteriorate rapidly.
2.5.36 exhibits this same behaviour (presumably for the same reason?).
Note the dip at exactly 100% and the peak either side of it?
-mm1 seems to do better than vanilla 2.5.36
Overall, vanilla 2.4.19 seems to respond more graded.
A quick reminder what these numbers are;
the data value is the time taken to compile a kernel, and the mem% is a
background memory load that continually asks for x% of the memory.
I'd like to include the ability to test this into a newer version of contest;
however the critical point when the results start to deteriorate, and the
absolute resolution required to show the difference will be dependent on the
test machine's memory. I haven't resolved the best way around this.
Con.
reply other threads:[~2002-09-20 14:07 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=1032531169.3d8b2ce16fb26@kolivas.net \
--to=conman@kolivas.net \
--cc=akpm@digeo.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®