2007/6/8, Eric Saxe <[EMAIL PROTECTED]>:
Thomas De Schampheleire wrote:
>
> What is meant with "between the chosen runq and the next one"? Does
> this mean that in the balancing only two queues will be checked? This
> means that there can be a great imbalance between two other cpu's
> right?
At that moment in time, yes. But the effectiveness of the routine relies
on the
fact that all CPUs take trips through the dispatcher fairly often. So if
A balances
with B, and B with C, and C with A, it works out. The logic here becomes
a bit
more complicated on NUMA systems, since the run queue balancing is only done
between CPUs in an lgroup...so this assumes that the thread to lgroup
affinities
are balanced as well.
(in the non-NUMA case):
the situation you describe suggests that the 'next' cpu changes. I
thought that the cpu lists would stay the same, as long as no cpus are
offlined?
> Suppose cpu0 has 2 threads, cpu1 can then have 4, cpu2 can have 6 and
> cpu3 can have 8. Between cpu3 and cpu0 there is now a difference of 6
> threads on their queues. A more balanced situation would be for each
> of these cpus to have 5 threads.
So cpu3 can balance against cpu0. :)
> In case only the 'next' cpu is checked, when the 'next' one is in the
> P_OFFLINE state, will it still be considered next, or will only active
> cpus be looked at?
Only active CPUs. Offline CPUs will be removed from the list that is
used for balancing
>
> I do not understand why the four threads on cpu3 are not balanced to
> cpu2, who is currently doing nothing. Cpu0 and cpu1 are currently
> offline. Is there something I am missing here?
Perhaps. So one detail that may be important here, is the balancing is
performed
between the per priority queues, not the CPUs total run queue. The idea
is that
if you have some threads at priority 0, some at priority 10, and some at
20, that
you'll have a fairly even distribution of 0, 10, and 20 priority threads
waiting for
each CPU. Otherwise, all the low priority threads could pile up on and
run on one CPU, while
higher priority threads sit in another CPU's queue. The code tries to
achieve a "parfait"
sort of effect. :)
But even in this case, it makes no sense to have one processor
completely idle, right?
-Eric
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
