mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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®