lkml.org 
[lkml]   [2003]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [BENCHMARK] 2.5.59-mm8 with contest
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.062 / U:2.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site