* Jos Poortvliet <jospoortvliet@gmail.com> wrote:

quoted text
> On 9/17/07, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Rob Hussey <robjhussey@gmail.com> 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:

quoted text
> > 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.

quoted text
> 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.

quoted text
> [...] 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
-
unsubscribe notice
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/