On 18/05/07, Peter Williams <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
