Re: 2.6.12-rc6-mm1

["Martin J. Bligh" <mbligh@mbligh.org>]

>> These tend to run together so just try adding my four patches together. In
>> retrospect I guess they're likely candidates because they also change the
>> _ratio_ of balance which they should not so they are buggy as a group
>> currently. Easy enough to fix but it will make it easy to pinpoint the
>> problem if they're responsible.
>> 
>> sched-implement-nice-support-across-physical-cpus-on-smp.patch
>> sched-change_prio_bias_only_if_queued.patch
>> sched-account_rt_tasks_in_prio_bias.patch
>> sched-smp-nice-bias-busy-queues-on-idle-rebalance.patch
> 
> By the way it has already been decided to remove these patches from -mm 
> pending the completion of current scheduler work. If they turn out to be 
> responsible for this regression I apologise profusely :-|. 
> 
> It is clearer to me now that I have made a mistake with the priority biasing, 
> and the following patch corrects it to the planned behaviour. This is 
> academic at this stage as we won't be looking at this particular feature 
> again in earnest until the other 32 scheduler patches (and any followups) go 
> upstream. 
> 
> It's already known that schedstats data will be off without further code to 
> understand smp nice as well (thanks Nick for pointing out the data)... more 
> academic stuff but obviously something to consider when/if we get there.

OK, I backed out those 4, and the degredation mostly went away.
See http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/perf/kernbench.moe.png

and more specifically, see the +p5150 near the right hand side.
I don't think it's quite as good as mainline, but much closer.
I did this run with HZ=1000, and the the one with no scheduler
patches at all with HZ=250, so I'll try to do a run that's more
directly comparable as well

Thanks,

M.