Re: [RFC] scheduler: improve SMP fairness in CFS
From: Chris Snook
Date: Wed Jul 25 2007 - 18:24:43 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/