Commit bb3485c8 authored Sep 07, 2018 by Vincent Guittot Committed by Ingo Molnar Sep 10, 2018

sched/fair: Fix load_balance redo for !imbalance



It can happen that load_balance() finds a busiest group and then a
busiest rq but the calculated imbalance is in fact 0.

In such situation, detach_tasks() returns immediately and lets the
flag LBF_ALL_PINNED set. The busiest CPU is then wrongly assumed to
have pinned tasks and removed from the load balance mask. then, we
redo a load balance without the busiest CPU. This creates wrong load
balance situation and generates wrong task migration.

If the calculated imbalance is 0, it's useless to try to find a
busiest rq as no task will be migrated and we can return immediately.

This situation can happen with heterogeneous system or smp system when
RT tasks are decreasing the capacity of some CPUs.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: jhugo@codeaurora.org
Link: http://lkml.kernel.org/r/1536306664-29827-1-git-send-email-vincent.guittot@linaro.org


Signed-off-by: Ingo Molnar <mingo@kernel.org>

parent 287cdaac

kernel/sched/fair.c

+1 −1

Original line number	Diff line number	Diff line
		@@ -8275,7 +8275,7 @@ static struct sched_group find_busiest_group(struct lb_env env)
		force_balance:
		/* Looks like there is an imbalance. Compute it */
		calculate_imbalance(env, &sds);
		return sds.busiest;
		return env->imbalance ? sds.busiest : NULL;

		out_balanced:
		env->imbalance = 0;

Admin message