Skip to content

Commit 16b0a7a

Browse files
vingu-linaroPeter Zijlstra
authored andcommitted
sched/fair: Ensure tasks spreading in LLC during LB
schbench shows latency increase for 95 percentile above since: commit 0b0695f ("sched/fair: Rework load_balance()") Align the behavior of the load balancer with the wake up path, which tries to select an idle CPU which belongs to the LLC for a waking task. calculate_imbalance() will use nr_running instead of the spare capacity when CPUs share resources (ie cache) at the domain level. This will ensure a better spread of tasks on idle CPUs. Running schbench on a hikey (8cores arm64) shows the problem: tip/sched/core : schbench -m 2 -t 4 -s 10000 -c 1000000 -r 10 Latency percentiles (usec) 50.0th: 33 75.0th: 45 90.0th: 51 95.0th: 4152 *99.0th: 14288 99.5th: 14288 99.9th: 14288 min=0, max=14276 tip/sched/core + patch : schbench -m 2 -t 4 -s 10000 -c 1000000 -r 10 Latency percentiles (usec) 50.0th: 34 75.0th: 47 90.0th: 52 95.0th: 78 *99.0th: 94 99.5th: 94 99.9th: 94 min=0, max=94 Fixes: 0b0695f ("sched/fair: Rework load_balance()") Reported-by: Chris Mason <[email protected]> Suggested-by: Rik van Riel <[email protected]> Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Rik van Riel <[email protected]> Tested-by: Rik van Riel <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
1 parent a73f863 commit 16b0a7a

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

kernel/sched/fair.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9031,7 +9031,8 @@ static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *s
90319031
* emptying busiest.
90329032
*/
90339033
if (local->group_type == group_has_spare) {
9034-
if (busiest->group_type > group_fully_busy) {
9034+
if ((busiest->group_type > group_fully_busy) &&
9035+
!(env->sd->flags & SD_SHARE_PKG_RESOURCES)) {
90359036
/*
90369037
* If busiest is overloaded, try to fill spare
90379038
* capacity. This might end up creating spare capacity

0 commit comments

Comments
 (0)