From: Con Kolivas <conman@kolivas.net>
To: Andrew Morton <akpm@digeo.com>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [BENCHMARK] 2.5.53-mm1 with contest
Date: Thu, 26 Dec 2002 23:56:44 +1100 [thread overview]
Message-ID: <200212262356.49802.conman@kolivas.net> (raw)
In-Reply-To: <3E0ACEBC.D06B1BAB@digeo.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 26 Dec 2002 08:41 pm, Andrew Morton wrote:
> Con Kolivas wrote:
> > ...
> > process_load:
> > Kernel [runs] Time CPU% Loads LCPU% Ratio
> > 2.5.52 [3] 84.4 79 17 19 1.26
> > 2.5.52-mm1 [7] 91.0 79 18 19 1.36
> > 2.5.52-mm2 [7] 90.3 79 18 19 1.35
> > 2.5.53 [7] 86.9 77 18 21 1.30
> > 2.5.53-mm1 [7] 117.1 58 47 40 1.75
> > Big change in the balance here in process_load. Probably a better balance
> > really given that process_load runs 4*num_cpus processes, and the kernel
> > compile is make -j (4*num_cpus)
>
> Presumably the run-child-first change. process_load is complex. I
> haven't looked into its dynamics and I'm not sure what, if anything,
> we can conclude from this test.
>
> > ...
> > The SMP results seem to fluctuate too much between runs even with the
> > average of 7 runs. I'm wondering whether I should even bother with them
> > any more as they dont add any useful information as far as I can see.
> > Comments on this would be appreciated. Andrew?
>
> Well for the sorts of things which you are interested in, SMP is not the
> target market, shall we say?
Agreed. Can't believe the initial UP v SMP results got slashdotted on
kerneltrap. I doubt anyone made any sense of them let alone made any useful
comment relating to them. I'll drop them in the interest of time and signal
to noise ratio.
> Is the variability seen in other kernels (especially 2.4)? If not then
> we'd need to find out what causes it.
A run through previous tests and a fresh run with vanilla 2.4.20 shows just as
much variation. It seems to be more a function of SMP rather than 2.5.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+CvyMF6dfvkL3i1gRAteoAKCqRu111T5ikGuYcUl4C7FgCjPvBgCfcUU7
gTiMlZxKT5KxjYDg+GeejkE=
=DbYb
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2002-12-26 12:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-26 8:34 [BENCHMARK] 2.5.53-mm1 with contest Con Kolivas
2002-12-26 9:41 ` Andrew Morton
2002-12-26 12:56 ` Con Kolivas [this message]
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=200212262356.49802.conman@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 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.