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>,
	Paolo Ciarrocchi <ciarrocchi@linuxmail.org>,
	Cliff White <cliffw@osdl.org>,
	Rodrigo Souza de Castro <rcastro@ime.usp.br>,
	Robinson@kolivas.net, Maureira@kolivas.net,
	"Castillo <rmaureira"@alumno.inacap.cl
Subject: [ANNOUNCE] contest 0.50 benchmark and updated results
Date: Sat, 5 Oct 2002 15:53:43 +1000	[thread overview]
Message-ID: <200210051554.26470.conman@kolivas.net> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've updated the contest benchmark to v0.50

http://contest.kolivas.net

A significant limitation of the benchmark prior to v0.50 was not knowing how 
much work was being done by the background load.  Knowing this information 
would be helpful in interpreting the data presented by contest. I have added 
two more results to each run by contest - an internal number generated by the 
load condition describing how much work was done, and the cpu% of the load 
while running.  Here is a sample of how the information is presented:

noload:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              67.7    98      0       0       1.01

process_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              106.5   59      112     43      1.59

io_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              492.6   14      38      10      7.33

mem_load:
Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.4.19 [3]              100.0   72      33      3       1.49

The "loads" variable presented is an internal number (the absolute value is 
not important) and makes comparisons easier. The LCPU% is the cpu% the load 
used while running. Note if you look for example at process_load the CPU% + 
LCPU% can be >100 because the load runs for longer than the kernel compile. 
However, this has been accounted for in the "loads" result, to take into 
account the variable extra duration the load runs relative to the kernel 
compile.

An updated complete set of benchmarks will be posted in a separate thread for 
clarity.

Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9nn5wF6dfvkL3i1gRAm7BAJkB7jh8eg71+DI307SMW74Aj+oSIACeKQ4h
i9Jx5CsdaKUspW5BB1/DSPU=
=gyF4
-----END PGP SIGNATURE-----

                 reply	other threads:[~2002-10-05  5:51 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=200210051554.26470.conman@kolivas.net \
    --to=conman@kolivas.net \
    --cc="Castillo <rmaureira"@alumno.inacap.cl \
    --cc=Maureira@kolivas.net \
    --cc=Robinson@kolivas.net \
    --cc=akpm@digeo.com \
    --cc=ciarrocchi@linuxmail.org \
    --cc=cliffw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rcastro@ime.usp.br \
    /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®