Re: [RFC] scheduler: improve SMP fairness in CFS

[Chris Snook <csnook@redhat.com>]

Li, Tong N wrote:
> On Wed, 2007-07-25 at 16:55 -0400, Chris Snook wrote:
>> Chris Friesen wrote:
>>> Ingo Molnar wrote:
>>>
>>>> the 3s is the problem: change that to 60s! We no way want to 
>>>> over-migrate for SMP fairness, the change i did gives us reasonable 
>>>> long-term SMP fairness without the need for high-rate rebalancing.
>>> Actually, I do have requirements from our engineering guys for 
>>> short-term fairness.  They'd actually like decent fairness over even 
>>> shorter intervals...1 second would be nice, 2 is acceptable.
>>>
>>> They are willing to trade off random peak performance for predictability.
>>>
>>> Chris
>>>
>> The sysctls for CFS have nanosecond resolution.  They default to 
>> millisecond-order values, but you can set them much lower.  See sched_fair.c for 
>> the knobs and their explanations.
>>
>> 	-- Chris
> 
> This is incorrect. Those knobs control local-CPU fairness granularity
> but have no control over fairness across CPUs.
> 
> I'll do some benchmarking as Ingo suggested.
> 
>   tong

CFS naturally enforces cross-CPU fairness anyway, as Ingo demonstrated. 
Lowering the local CPU parameters should cause system-wide fairness to converge 
faster.  It might be worthwhile to create a more explicit knob for this, but I'm 
inclined to believe we could do it in much less than 700 lines.  Ingo's 
one-liner to improve the 10/8 balancing case, and the resulting improvement, 
were exactly what I was saying should be possible and desirable.  TCP Nagle 
aside, it generally shouldn't take 700 lines of code to speed up the rate of 
convergence of something that already converges.

Until now I've been watching the scheduler rewrite from the sidelines, but I'm 
digging into it now.  I'll try to give some more constructive criticism soon.

	-- Chris