Messages in this thread | | | Date | Mon, 21 May 2007 17:25:48 +0200 | From | "Dmitry Adamushko" <> | Subject | Re: [patch] CFS scheduler, -v12 |
| |
On 18/05/07, Peter Williams <pwil3058@bigpond.net.au> wrote: [...] > One thing that might work is to jitter the load balancing interval a > bit. The reason I say this is that one of the characteristics of top > and gkrellm is that they run at a more or less constant interval (and, > in this case, X would also be following this pattern as it's doing > screen updates for top and gkrellm) and this means that it's possible > for the load balancing interval to synchronize with their intervals > which in turn causes the observed problem.
Hum.. I guess, a 0/4 scenario wouldn't fit well in this explanation.. all 4 spinners "tend" to be on CPU0 (and as I understand each gets ~25% approx.?), so there must be plenty of moments for *idle_balance()* to be called on CPU1 - as gkrellm, top and X consume together just a few % of CPU. Hence, we should not be that dependent on the load balancing interval here..
(unlikely consiparacy theory) - idle_balance() and load_balance() (the later is dependent on the load balancing interval which can be in sync. with top/gkerllm activities as you suggest) move always either top or gkerllm between themselves.. esp. if X is reniced (so it gets additional "weight") and happens to be active (on CPU1) when load_balance() (kicked from scheduler_tick()) runs..
p.s. it's mainly theoretical specualtions.. I recently started looking at the load-balancing code (unfortunatelly, don't have an SMP machine which I can upgrade to the recent kernel) and so far for me it's mainly about getting sure I see things sanely.
-- Best regards, Dmitry Adamushko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |