Re: [ck] Re: Scheduler benchmarks - a follow-up

From: Ingo Molnar
Date: Mon Sep 17 2007 - 10:12:50 EST



* Jos Poortvliet <jospoortvliet@xxxxxxxxx> wrote:

> On 9/17/07, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Rob Hussey <robjhussey@xxxxxxxxx> wrote:
> >
> > > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
> >
> > heh - am i the only one impressed by the consistency of the blue line in
> > this graph? :-) [ and the green line looks a bit like a .. staircase? ]
>
> Looks lovely, though as long as lower is better, that staircase does a
> nice job ;-)

lower is better, but you have to take the thing below into account:

> > i've meanwhile tested hackbench 90 and the performance difference
> > between -ck and -cfs-devel seems to be mostly down to the more precise
> > (but slower) sched_clock() introduced in v2.6.23 and to the startup
> > penalty of freshly created tasks.
> >
> > Putting back the 2.6.22 version and tweaking the startup penalty gives
> > this:
> >
> > [hackbench 90, smaller is better]
> >
> > sched-devel.git sched-devel.git+lowres-sched-clock+dsp
> > --------------- --------------------------------------
> > 5.555 5.149
> > 5.641 5.149
> > 5.572 5.171
> > 5.583 5.155
> > 5.532 5.111
> > 5.540 5.138
> > 5.617 5.176
> > 5.542 5.119
> > 5.587 5.159
> > 5.553 5.177
> > --------------------------------------
> > avg: 5.572 avg: 5.150 (-8.1%)
>
> Hmmm. So cfs was 0.8% slower compared to ck in the test by Rob, it
> became 8% faster so... it should be faster than CK - provided these
> results are valid over different tests.

on my box the TSC overhead has hit CFS quite hard, i'm not sure that's
true on Rob's box. So i'd expect them to be in roughly the same area.

> But this is all microbenchmarks, which won't have much effect in real
> life, right? [...]

yeah, it's much less pronounced in real life - a context-switch rate
above 10,000/sec is already excessive - while for example the lat_ctx
test generates close to a million context switches a second.

> [...] Besides, will the lowres sched clock patch get in?

i dont think so - we want precise/accurate scheduling before
performance. (otherwise tasks working off the timer tick could steal
away cycles without being accounted for them fairly, and could starve
out all other tasks.) Unless the difference was really huge in real life
- but it isnt.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/