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>

authored by

Vincent Guittot and committed by
Ingo Molnar
bb3485c8 287cdaac

+1 -1
+1 -1
kernel/sched/fair.c
··· 8275 force_balance: 8276 /* Looks like there is an imbalance. Compute it */ 8277 calculate_imbalance(env, &sds); 8278 - return sds.busiest; 8279 8280 out_balanced: 8281 env->imbalance = 0;
··· 8275 force_balance: 8276 /* Looks like there is an imbalance. Compute it */ 8277 calculate_imbalance(env, &sds); 8278 + return env->imbalance ? sds.busiest : NULL; 8279 8280 out_balanced: 8281 env->imbalance = 0;