[lkml]   [2003]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BENCHMARK] 2.5.63-mm2 + i/o schedulers with contest
On Tue, 4 Mar 2003 03:18 pm, Nick Piggin wrote:
> Con Kolivas wrote:
> >Here are contest ( benchmarks using the osdl
> >hardware ( 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:
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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