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: <20140729152705.GX12054@laptop.lan>
Date:	Tue, 29 Jul 2014 17:27:05 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	Rik van Riel <riel@...hat.com>,
	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

On Tue, Jul 29, 2014 at 04:59:10PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 29, 2014 at 11:04:50AM +0200, Vincent Guittot wrote:
> > > In situations where all the domains are overloaded, or where only the
> > > busiest domain is overloaded, that code is also superfluous, since
> > > the normal env->imbalance calculation will figure out how much to move.
> > > Remove the load_above_capacity calculation.
> > 
> > IMHO, we should not remove that part which is used by prefer_sibling
> > 
> > Originally, we had 2 type of busiest group: overloaded or imbalanced.
> > You add a new one which has only a avg_load higher than other so you
> > should handle this new case and keep the other ones unchanged
> 
> 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.

Which would be patch 3/2

---
Subject: sched,fair: Allow calculate_imbalance() to move idle cpus
From: Peter Zijlstra <peterz@...radead.org>
Date: Tue Jul 29 17:15:11 CEST 2014

Allow calculate_imbalance() to 'create' idle cpus in the busiest group
if there are idle cpus in the local group.

Suggested-by: Rik van Riel <riel@...hat.com>
Signed-off-by: Peter Zijlstra <peterz@...radead.org>
Link: http://lkml.kernel.org/n/tip-7k95k4i2tjv78iivstggiude@git.kernel.org
---
 kernel/sched/fair.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6273,12 +6273,11 @@ static inline void calculate_imbalance(s
 		return fix_small_imbalance(env, sds);
 	}
 
-	if (busiest->group_type == group_overloaded) {
-		/*
-		 * Don't want to pull so many tasks that a group would go idle.
-		 * Except of course for the group_imb case, since then we might
-		 * have to drop below capacity to reach cpu-load equilibrium.
-		 */
+	/*
+	 * If there aren't any idle cpus, avoid creating some.
+	 */
+	if (busiest->group_type == group_overloaded &&
+	    local->group_type   == group_overloaded) {
 		load_above_capacity =
 			(busiest->sum_nr_running - busiest->group_capacity_factor);
 
--
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/