linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rodrigo Souza de Castro <rcastro@ime.usp.br>
To: Andrew Morton <akpm@digeo.com>
Cc: Paolo Ciarrocchi <ciarrocchi@linuxmail.org>,
	conman@kolivas.net, linux-kernel@vger.kernel.org,
	rmaureira@alumno.inacap.cl
Subject: Re: [BENCHMARK] contest 0.50 results to date
Date: Sat, 5 Oct 2002 17:56:27 -0300	[thread overview]
Message-ID: <20021005205627.GA1386@vinci> (raw)
In-Reply-To: <3D9F3A52.4FB46701@digeo.com>

On Sat, Oct 05, 2002 at 12:15:30PM -0700, Andrew Morton wrote:
> Paolo Ciarrocchi wrote:
> > 
[snip]
> > mem_load:
> > Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
> > 2.4.19 [3]              161.1   80      38      2       1.26
> > 2.4.19-0.24pre4 [3]     181.2   76      253     19      1.41
> > 2.5.40 [3]              163.0   80      34      2       1.27
> > 2.5.40-nopree [3]       161.7   80      34      2       1.26
> > 
> 
> I think I'm going to have to be reminded what "Loads" and "LCPU"
> mean, please.
> 
> For these sorts of tests, I think system-wide CPU% is an interesting
> thing to track - both user and system.  If it is high then we're doing
> well - doing real work.
> 
> The same isn't necessarily true of the compressed-cache kernel, because
> it's doing extra work in-kernel, so CPU load comparisons there need
> to be made with some caution.

Agreed. 

I guess the scheduling is another important point here. Firstly, this
extra work, usually not substantial, may change a little the
scheduling in the system.

Secondly, given that compressed cache usually reduces the IO performed
by the system, it may change the scheduling depending on how much IO
it saves and on what the applications do. For example, mem_load
doesn't swap any page when compressed cache is enabled (those data are
highly compressible), turning out to use most of its CPU time
slice. In vanilla, mem_load is scheduled all the time to service page
faults.

-- 
Rodrigo



  reply	other threads:[~2002-10-05 20:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-05 18:28 [BENCHMARK] contest 0.50 results to date Paolo Ciarrocchi
2002-10-05 19:15 ` Andrew Morton
2002-10-05 20:56   ` Rodrigo Souza de Castro [this message]
2002-10-06  1:03   ` Con Kolivas
2002-10-06  5:38   ` load additions to contest Con Kolivas
2002-10-06  6:11     ` Andrew Morton
2002-10-06  6:56       ` Con Kolivas
2002-10-06 12:07       ` Con Kolivas
  -- strict thread matches above, loose matches on Subject: below --
2002-10-05 19:28 [BENCHMARK] contest 0.50 results to date Paolo Ciarrocchi
2002-10-05  5:59 Con Kolivas

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=20021005205627.GA1386@vinci \
    --to=rcastro@ime.usp.br \
    --cc=akpm@digeo.com \
    --cc=ciarrocchi@linuxmail.org \
    --cc=conman@kolivas.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmaureira@alumno.inacap.cl \
    /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;
as well as URLs for NNTP newsgroup(s).