Re: [BENCHMARK] 2.5.63-mm2 + i/o schedulers with contest

[Con Kolivas <kernel@kolivas.org>]

On Tue, 4 Mar 2003 03:18 pm, Nick Piggin wrote:
> Con Kolivas wrote:
> >Here are contest (http://contest.kolivas.org) benchmarks using the osdl
> >hardware (http://www.osdl.org) for 2.5.63-mm2 and various i/o schedulers:
>
> Thanks :)
>
> >It seems the AS scheduler reliably takes slightly longer to compile the
> > kernel in no load conditions, but only about 1% cpu.
>
> It is likely that AS will wait too long for gcc to submit another
> read and end up timing out anyway. Hopefully IO history tracking
> will fix this up - for some loads the effect can be much worse.
>
> >CFQ and DL faster to compile the kernel than AS while extracting or
> > creating tars.
>
> This is likely to be balancing differences from LCPU% it does
> seem like AS is doing a bit more "load" work.
>
> >AS significantly faster under writing large file to the same disk
> > (io_load) or other disk (io_other) conditions. The CFQ and DL schedulers
> > showed much more variability on io_load during testing but did not drop
> > below 140 seconds.
>
> small randomish reads vs large writes _is_ where AS really can
> perform better than non a non AS scheduler. Unfortunately gcc
> doesn't have the _best_ IO pattern for AS ;)

Yes I recall this discussion against a gcc based benchmark. However it is 
interesting that it still performed by far the best.

> >CFQ and DL scheduler were faster compiling the kernel under read_load,
> >list_load and dbench_load.
> >
> >Mem_load result of AS being slower was just plain weird with the result
> > rising from 100 to 150 during testing.
>
> I would like to see if AS helps much with a swap/memory
> thrashing load.

That's what mem_load is. It repeatedly tries to access 110% of available ram.
quote from original post:
mem_load:
Kernel         [runs]   Time    CPU%    Loads   LCPU%   Ratio
2.5.63              3   104     75.0    57.7    1.9     1.32
2.5.63-mm2cfq       3   101     76.2    52.3    2.0     1.28
2.5.63-mm2          3   132     59.1    90.3    2.3     1.65
2.5.63-mm2dl        3   100     79.0    52.0    2.0     1.27

Note that mm2 with AS performed equivalent to the other schedulers but on 
later runs took longer. (99, 148,150) This is usually suspicious of a memory 
leak that contest is unusually sensitive at picking up, but there wasn't 
anything suspicious about the meminfo after these runs, and none of the other 
loads changed over time. io_load usually shows drastic prolongation when 
memory is leaking.

Con