Re: [PATCH] Load balancing problem in 2.6.2-mm1

[Nick Piggin <piggin@cyberone.com.au>]

Martin J. Bligh wrote:

>>>If CPU 8 has 2 tasks, and cpu 1 has 1 task, there's an imbalance of 1.
>>>*If* that imbalance persists (and it probably won't, given tasks being
>>>created, destroyed, and blocking for IO), we may want to rotate that 
>>>to 1 vs 2, and then back to 2 vs 1, etc. in the interests of fairness,
>>>even though it's slower throughput overall.
>>>
>>>
>>Yes, although as long as it's node local and happens a couple of
>>times a second you should be pretty hard pressed noticing the
>>difference.
>>
>
>Not sure how true that turns out to be in practice ... probably depends
>heavily on both the workload (how heavily it's using the cache) and the
>chip (larger caches have proportionately more to lose).
>
>As we go forward in time, cache warmth gets increasingly important, as
>CPUs accelerate speeds quicker than memory. Cache sizes also get larger.
>I'd really like us to be conservative here - the unfairness thing is 
>really hard to hit anyway - you need a static number of processes that
>don't ever block on IO or anything.
>
>

Can we keep current behaviour default, and if arches want to
override it they can? And if someone one day does testing to
show it really isn't a good idea, then we can change the default.

I like to try stick to the fairness first approach.

We got quite a few complaints about unfairness when the
scheduler used to keep 2 on one cpu and 1 on another, even in
development kernels. I suspect that most wouldn't have known
one way or the other if only top showed 66% each, but still.