Re: [PATCH 1/2] sched: fix and clean up calculate_imbalance

From: Rik van Riel
Date: Tue Jul 29 2014 - 13:05:13 EST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/29/2014 11:49 AM, Peter Zijlstra wrote:
> On Tue, Jul 29, 2014 at 11:15:49AM -0400, Rik van Riel wrote:
>
>>> Right, so we want that code for overloaded -> overloaded
>>> migrations such as not to cause idle cpus in an attempt to
>>> balance things. Idle cpus are worse than imbalance.
>>>
>>> But in case of overloaded/imb -> !overloaded migrations we can
>>> allow it, and in fact want to allow it in order to balance
>>> idle cpus.
>>
>> In case the destination is over the average load, or the source
>> is under the average load, fix_small_imbalance() determines
>> env->imbalance.
>>
>> The "load_above_capacity" calculation is only reached when
>> busiest is busier than average, and the destination is under the
>> average load. In that case, env->imbalance ends up as the minimum
>> of busiest - avg and avg - target.
>>
>> Is there any case where limiting it further to "load - capacity"
>> from the busiest domain makes a difference?
>
> sadly yes; suppose 8 cpus in 2 groups and 9 tasks, 8 tasks of
> weight 10, 1 of 1024. The local group will have 5 tasks of 10, the
> busiest will have the remaining 4.

Good point!

Looks like your patches address all issues raised, and the code
looks nicer than before.

- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT19QSAAoJEM553pKExN6DM+EH/A0VSAcLB5TIDOC9axBwxdtY
RxDkYvGZJ9OvbsU83alpjm+ee5l1x+A1tKQofqd1QVDSfpq9QPrUniueeqnNyJhM
/alIRP/09bmH8vdn0uTqVrrx/lESeNPop5KmWimAdm1s452Lz8iuU3KmZryGssyJ
MolSWGKwNbWIncBLRtkNB7szlkLyvO0JZQN5FnA1xrzDZeaCA9j072t/49fiscbs
t6O8LxxsyooM+Wj3KyNt5dSKb9kHKf9gg0Z1dwcEqpcBjTB1jZNwOLQfhhaXX4gX
Gu55x8bJzFRMLey1EVtzlM7gnjpgiELbyfB7JibN0I8pYJKS9EcybCjQuq7BuvA=
=dt7v
-----END PGP SIGNATURE-----
--
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/