linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Con Kolivas <conman@kolivas.net>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BENCHMARK] 2.5.59-mm8 with contest
Date: Fri, 7 Feb 2003 21:26:20 +1100	[thread overview]
Message-ID: <200302072126.20826.conman@kolivas.net> (raw)
In-Reply-To: <20030207002202.5066e9c2.akpm@digeo.com>

On Fri, 7 Feb 2003 07:22 pm, Andrew Morton wrote:
> Con Kolivas <conman@kolivas.net> wrote:
> > On Thu, 6 Feb 2003 07:37 am, Andrew Morton wrote:
> > > Con Kolivas wrote:
> > > > ..
> > > >
> > > > This seems to be creeping up to the same as 2.5.59
> > > > ...
> > > > and this seems to be taking significantly longer
> > > > ...
> > > > And this load which normally changes little has significantly
> > > > different results.
> > >
> > > There were no I/O scheduler changes between -mm7 and -mm8.  I
> > > demand a recount!
> >
> > Repeated mm7 and mm8.
> > Recount-One for Martin, two for Martin. Same results; not the i/o
> > scheduler responsible for the changes, but I have a sneaking suspicion
> > another scheduler may be.
>
> Not sure.
>
> With contest 0.60, io_load, ext3, with the scheduler changes:
>
> Finished compiling kernel: elapsed: 161 user: 181 system: 16
> Finished io_load: elapsed: 162 user: 0 system: 17 loads: 9
> Finished compiling kernel: elapsed: 155 user: 179 system: 15
> Finished io_load: elapsed: 155 user: 0 system: 17 loads: 9
> Finished compiling kernel: elapsed: 166 user: 180 system: 15
> Finished io_load: elapsed: 166 user: 0 system: 18 loads: 10
>

average of 162/108 (io_load over no_load) prolongs it 50% for one process 
(disk writing) when eight processes are running (kernel compile)
on my uniprocessor results it's 92% prolongation for one v four

>
> With the CPU scheduler changes backed out:
>
> Finished compiling kernel: elapsed: 137 user: 181 system: 14
> Finished io_load: elapsed: 138 user: 0 system: 9 loads: 5
> Finished compiling kernel: elapsed: 142 user: 181 system: 14
> Finished io_load: elapsed: 142 user: 0 system: 9 loads: 5
> Finished compiling kernel: elapsed: 133 user: 181 system: 15
> Finished io_load: elapsed: 133 user: 0 system: 12 loads: 7
>
> So there's some diminution there, not a lot.

average of 133/108 prolongs it 27% for one process when eight processes are 
running.
on my results it's 44% prolongation

> With no_load:
>
> Finished compiling kernel: elapsed: 108 user: 179 system: 12
> Finished no_load: elapsed: 108 user: 7 system: 12 loads: 0
> Finished compiling kernel: elapsed: 107 user: 179 system: 13
> Finished no_load: elapsed: 107 user: 7 system: 12 loads: 0
> Finished compiling kernel: elapsed: 110 user: 178 system: 12
> Finished no_load: elapsed: 110 user: 8 system: 14 loads: 0
>
>
> It's very good either way.  Probably with the scheduler changes we're
> hitting a better balance.

I would have thought that the one disk write heavy process is getting more 
than the lion's share with the new scheduler changes, and the mm7 results 
were fairer?

Con

      reply	other threads:[~2003-02-07 10:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-05 11:21 [BENCHMARK] 2.5.59-mm8 with contest Con Kolivas
2003-02-05 20:37 ` Andrew Morton
2003-02-06  1:02   ` Nick Piggin
2003-02-06  8:08   ` Con Kolivas
2003-02-07  8:22     ` Andrew Morton
2003-02-07 10:26       ` 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=200302072126.20826.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 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).