Re: [tbench regression fixes]: digging out smelly deadmen.

[Ingo Molnar <mingo@elte.hu>]

* Mike Galbraith <efault@gmx.de> wrote:

> ..removing the overhead from .27 does not produce the anticipated 
> result despite a max context switch rate markedly above that of 
> 2.6.26.
> 
> There lies an as yet unaddressed regression IMBHO.  The hrtick has 
> been addressed.  It sucked at high frequency, and it's gone.  The 
> added math overhead in .27 hurt some too, and is now history as 
> well.

thanks Mike for the _extensive_ testing and bug hunting session you've 
done in the past couple of weeks! All the relevant fixlets you found 
are now queued up properly in sched/urgent, correct?

What's your gut feeling, is that remaining small regression scheduler 
or networking related?

i'm cutting the ball in half and i'm passing over one half of it to 
the networking folks, because your numbers show _huge_ sensitivity in 
this workload, depending on networking settings:

> To really illustrate rockiness, cutting network config down from distro
> lard-ball to something leaner and meaner took SMP throughput from this
> (was only testing netperf at that time) on 19 Aug..
> 
> 2.6.22.19 pinned
> 16384  87380  1        1       300.00   59866.40   

> 2.6.22.19 (also pinned)
> 16384  87380  1        1       60.01    94179.12

> 2.6.22.19 (also pinned)
> 16384  87380  1        1       60.01    111272.55  1.00

any scheduler micro-overhead detail is going to be a drop in the 
ocean, compared to such huge variations. We could change the scheduler 
to the old O(N) design of the 2.2 kernel and the impact of that would 
be a blip on the radar, compared to the overhead shown above.

	Ingo