Messages in this thread | | | Date | Thu, 9 Feb 2023 21:17:05 +0800 | From | Chen Yu <> | Subject | Re: [PATCH v3 06/10] sched/fair: Use the prefer_sibling flag of the current sched domain |
| |
On 2023-02-06 at 20:58:34 -0800, Ricardo Neri wrote: > SD_PREFER_SIBLING is set from the SMT scheduling domain up to the first > non-NUMA domain (the exception is systems with SD_ASYM_CPUCAPACITY). > > Above the SMT sched domain, all domains have a child. The SD_PREFER_ > SIBLING is honored always regardless of the scheduling domain at which the > load balance takes place. > > There are cases, however, in which the busiest CPU's sched domain has > child but the destination CPU's does not. Consider, for instance a non-SMT > core (or an SMT core with only one online sibling) doing load balance with > an SMT core at the MC level. SD_PREFER_SIBLING will not be honored. We are > left with a fully busy SMT core and an idle non-SMT core. > > Avoid inconsistent behavior. Use the prefer_sibling behavior at the current > scheduling domain, not its child. > > The NUMA sched domain does not have the SD_PREFER_SIBLING flag. Thus, we > will not spread load among NUMA sched groups, as desired. > > Cc: Ben Segall <bsegall@google.com> > Cc: Daniel Bristot de Oliveira <bristot@redhat.com> > Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> > Cc: Len Brown <len.brown@intel.com> > Cc: Mel Gorman <mgorman@suse.de> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: Tim C. Chen <tim.c.chen@intel.com> > Cc: Valentin Schneider <vschneid@redhat.com> > Cc: x86@kernel.org > Cc: linux-kernel@vger.kernel.org > Suggested-by: Valentin Schneider <vschneid@redhat.com> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> > --- > Changes since v2: > * Introduced this patch. > > Changes since v1: > * N/A > --- > kernel/sched/fair.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index df7bcbf634a8..a37ad59f20ea 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -10004,7 +10004,6 @@ static void update_idle_cpu_scan(struct lb_env *env, > > static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sds) > { > - struct sched_domain *child = env->sd->child; > struct sched_group *sg = env->sd->groups; > struct sg_lb_stats *local = &sds->local_stat; > struct sg_lb_stats tmp_sgs; > @@ -10045,9 +10044,11 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd > sg = sg->next; > } while (sg != env->sd->groups); > > - /* Tag domain that child domain prefers tasks go to siblings first */ > - sds->prefer_sibling = child && child->flags & SD_PREFER_SIBLING; > - > + /* > + * Tag domain that @env::sd prefers to spread excess tasks among > + * sibling sched groups. > + */ > + sds->prefer_sibling = env->sd->flags & SD_PREFER_SIBLING; > This does help fix the issue that non-SMT core fails to pull task from busy SMT-cores. And it also semantically changes the definination of prefer sibling. Do we also need to change this: if ((sd->flags & SD_ASYM_CPUCAPACITY) && sd->child) sd->child->flags &= ~SD_PREFER_SIBLING; might be: if ((sd->flags & SD_ASYM_CPUCAPACITY)) sd->flags &= ~SD_PREFER_SIBLING;
thanks, Chenyu
>
| |