From: Ricardo Neri Date: Thu, 6 Apr 2023 20:31:41 +0000 (-0700) Subject: sched/fair: Keep a fully_busy SMT sched group as busiest X-Git-Tag: v6.6.17~4590^2~45 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=5fd6d7f43958cb62da105c8413eac3e78480f09a;p=platform%2Fkernel%2Flinux-rpi.git sched/fair: Keep a fully_busy SMT sched group as busiest When comparing two fully_busy scheduling groups, keep the current busiest group if it represents an SMT core. Tasks in such scheduling group share CPU resources and need more help than tasks in a non-SMT fully_busy group. Signed-off-by: Ricardo Neri Signed-off-by: Peter Zijlstra (Intel) Tested-by: Zhang Rui Link: https://lore.kernel.org/r/20230406203148.19182-6-ricardo.neri-calderon@linux.intel.com --- diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 85ce249..4a9f040 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9619,10 +9619,22 @@ static bool update_sd_pick_busiest(struct lb_env *env, * contention when accessing shared HW resources. * * XXX for now avg_load is not computed and always 0 so we - * select the 1st one. + * select the 1st one, except if @sg is composed of SMT + * siblings. */ - if (sgs->avg_load <= busiest->avg_load) + + if (sgs->avg_load < busiest->avg_load) return false; + + if (sgs->avg_load == busiest->avg_load) { + /* + * SMT sched groups need more help than non-SMT groups. + * If @sg happens to also be SMT, either choice is good. + */ + if (sds->busiest->flags & SD_SHARE_CPUCAPACITY) + return false; + } + break; case group_has_spare: