Skip to content

Commit 6d7e478

Browse files
mu-mu-muPeter Zijlstra
authored andcommitted
sched/fair: Fix the decision for load balance
should_we_balance is called for the decision to do load-balancing. When sched ticks invoke this function, only one CPU should return true. However, in the current code, two CPUs can return true. The following situation, where b means busy and i means idle, is an example, because CPU 0 and CPU 2 return true. [0, 1] [2, 3] b b i b This fix checks if there exists an idle CPU with busy sibling(s) after looking for a CPU on an idle core. If some idle CPUs with busy siblings are found, just the first one should do load-balancing. Fixes: b1bfeab ("sched/fair: Consider the idle state of the whole core for load balance") Signed-off-by: Keisuke Nishimura <keisuke.nishimura@inria.fr> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Shrikanth Hegde <sshegde@linux.vnet.ibm.com> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lkml.kernel.org/r/20231031133821.1570861-1-keisuke.nishimura@inria.fr
1 parent 8b39d20 commit 6d7e478

File tree

1 file changed

+7
-3
lines changed

1 file changed

+7
-3
lines changed

kernel/sched/fair.c

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -11184,12 +11184,16 @@ static int should_we_balance(struct lb_env *env)
1118411184
continue;
1118511185
}
1118611186

11187-
/* Are we the first idle CPU? */
11187+
/*
11188+
* Are we the first idle core in a non-SMT domain or higher,
11189+
* or the first idle CPU in a SMT domain?
11190+
*/
1118811191
return cpu == env->dst_cpu;
1118911192
}
1119011193

11191-
if (idle_smt == env->dst_cpu)
11192-
return true;
11194+
/* Are we the first idle CPU with busy siblings? */
11195+
if (idle_smt != -1)
11196+
return idle_smt == env->dst_cpu;
1119311197

1119411198
/* Are we the first CPU of this group ? */
1119511199
return group_balance_cpu(sg) == env->dst_cpu;

0 commit comments

Comments
 (0)