linux-kernel - Re: [PATCH 1/2] sched: fix and clean up calculate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53D7D412.4040203@redhat.com>
Date:	Tue, 29 Jul 2014 13:04:18 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Michael Neuling <mikey@...ling.org>,
	Ingo Molnar <mingo@...nel.org>, jhladky@...hat.com,
	ktkhai@...allels.com, tim.c.chen@...ux.intel.com,
	Nicolas Pitre <nicolas.pitre@...aro.org>
Subject: Re: [PATCH 1/2] sched: fix and clean up calculate_imbalance

-----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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/