[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53D7C01B.9060801@redhat.com>
Date: Tue, 29 Jul 2014 11:39:07 -0400
From: Rik van Riel <riel@...hat.com>
To: Vincent Guittot <vincent.guittot@...aro.org>
CC: linux-kernel <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.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:31 AM, Vincent Guittot wrote:
> On 29 July 2014 16:53, Rik van Riel <riel@...hat.com> wrote:
>> I cannot think of any case where keeping the "overloaded" code
>> would result in the code behaving differently over the long
>> term.
>
>> What am I overlooking?
>
> IIUC the load_above_capacity is there to prevent the busiest group
> to become idle and you remove that protection
Having the busiest group become partially idle is perfectly fine,
as long as there is also spare capacity in the destination group.
Spreading out the work load over more CPU sockets, with more CPU
cache and more total available memory bandwidth is often a good
thing.
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJT18AbAAoJEM553pKExN6DaLoH/RzCR/YWDYe4/tZEC/sHn89l
jCOVdoY2ZkVHx/yO1Vd0UeoAE94XFsiw0sKwy0lVXLxi3nBIjfh41qZkGoS2lQuo
YSi7PE2o6T5WmluEQfTnUn1DAX0sigUYvWAxnpDYM6I+m8RS0QB7VYSaoqaT3T8D
qomO8FmBN75JrwoywWBDiVRjnxfQJzt6bBK92GUIo6+af6RUSQ9xwQg6EPp3E3r6
FFqIHJ6HaRFCml1KMD4azopVC/bbbhvnbE/EO/5In2nbBsVK06XpBlLWfCyiD48q
NkjnAjISweWTCoMdhULaXdLGeWH85DWoDtvDTCbK+m/QBXRXdiAbij0fDFDhPck=
=QIq6
-----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/
Powered by blists - more mailing lists