All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Christian Loehle <christian.loehle@arm.com>,
	Koba Ko <kobak@nvidia.com>,
	Felix Abecassis <fabecassis@nvidia.com>,
	Balbir Singh <balbirs@nvidia.com>,
	Joel Fernandes <joelagnelf@nvidia.com>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] sched/fair: Add SIS_UTIL support to select_idle_capacity()
Date: Fri, 24 Apr 2026 19:13:33 +0200	[thread overview]
Message-ID: <aeukvYcx0yLaPvps@gpd4> (raw)
In-Reply-To: <CAKfTPtDKjdX3Dpxvf8stBMALXFP9YGnkhk-gbRpP_Zoenk6GeQ@mail.gmail.com>

Hi Vincent,

On Fri, Apr 24, 2026 at 02:32:30PM +0200, Vincent Guittot wrote:
> On Thu, 23 Apr 2026 at 09:42, Andrea Righi <arighi@nvidia.com> wrote:
> >
> > From: K Prateek Nayak <kprateek.nayak@amd.com>
> >
> > Add to select_idle_capacity() the same SIS_UTIL-controlled idle-scan
> > mechanism, already used by select_idle_cpu(): when sched_feat(SIS_UTIL)
> > is enabled and the LLC domain has sched_domain_shared data, derive the
> > per-attempt scan limit from sd->shared->nr_idle_scan.
> >
> > That bounds the walk on large LLCs and allows an early return once the
> > scan limit is reached, if we already picked a sufficiently strong
> > idle-core candidate (best_fits == -4).
> >
> > Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> > ---
> >  kernel/sched/fair.c | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 9bd9dc6e0882e..6b67049f04c3e 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -8002,6 +8002,7 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
> >         int fits, best_fits = 0;
> >         int cpu, best_cpu = -1;
> >         struct cpumask *cpus;
> > +       int nr = INT_MAX;
> >
> >         cpus = this_cpu_cpumask_var_ptr(select_rq_mask);
> >         cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> > @@ -8010,10 +8011,30 @@ select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
> >         util_min = uclamp_eff_value(p, UCLAMP_MIN);
> >         util_max = uclamp_eff_value(p, UCLAMP_MAX);
> >
> > +       if (sched_feat(SIS_UTIL) && sd->shared) {
> > +               /*
> > +                * Increment because !--nr is the condition to stop scan.
> > +                *
> > +                * Since "sd" is "sd_llc" for target CPU dereferenced in the
> > +                * caller, it is safe to directly dereference "sd->shared".
> > +                * Topology bits always ensure it assigned for "sd_llc" and it
> > +                * cannot disappear as long as we have a RCU protected
> > +                * reference to one the associated "sd" here.
> > +                */
> > +               nr = READ_ONCE(sd->shared->nr_idle_scan) + 1;
> > +               /* overloaded LLC is unlikely to have idle cpu/core */
> > +               if (nr == 1)
> > +                       return -1;
> 
> The comment below applies to select_idle_cpu but we want same behavior
> for both function
> If test_idle_cores is true we will not look for it whereas we don't
> care about nr value when test_idle_core is true in the
> for_each_cpu_wrap loop
> 
> 
> > +       }
> > +
> >         for_each_cpu_wrap(cpu, cpus, target) {
> >                 bool preferred_core = !prefers_idle_core || is_core_idle(cpu);
> >                 unsigned long cpu_cap = capacity_of(cpu);
> >
> > +               /* We have found a good enough target. Just use it. */
> > +               if (--nr <= 0 && best_fits == -4)
> > +                       return best_cpu;
> 
> In select_idle_cpu(), we return immediatly when nr == 0 and
> test_idle_cores is false but we loop on all cpus if test_idle_cores is
> true until we found an idle core. In the case of
> select_idle_capacity(), I agree that util_fits_cpu() add another level
> but shouldn't we continue to loop even if we found a best_fits == -4
> 

Agreed that we should keep the behavior consistent between select_idle_cpu() and
select_idle_capacity().

I ran some quick tests with nr / early return matching select_idle_cpu() (using
the SIS_UTIL scan cap only with !prefers_idle_core). So far, I'm not seeing any
noticeable performance difference on my side, so that looks fine to me.

Thanks,
-Andrea

  reply	other threads:[~2026-04-24 17:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23  7:36 [PATCH v3 0/5] sched/fair: SMT-aware asymmetric CPU capacity Andrea Righi
2026-04-23  7:36 ` [PATCH 1/5] sched/fair: Attach sched_domain_shared to sd_asym_cpucapacity Andrea Righi
2026-04-24  5:14   ` K Prateek Nayak
2026-04-24  8:46     ` Andrea Righi
2026-04-24 11:18       ` K Prateek Nayak
2026-04-24 23:29         ` Andrea Righi
2026-04-23  7:36 ` [PATCH 2/5] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection Andrea Righi
2026-04-24  5:42   ` K Prateek Nayak
2026-04-23  7:36 ` [PATCH 3/5] sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity Andrea Righi
2026-04-24  5:37   ` K Prateek Nayak
2026-04-24  9:21     ` Andrea Righi
2026-04-23  7:36 ` [PATCH 4/5] sched/fair: Add SIS_UTIL support to select_idle_capacity() Andrea Righi
2026-04-24  5:55   ` K Prateek Nayak
2026-04-24 12:32   ` Vincent Guittot
2026-04-24 17:13     ` Andrea Righi [this message]
2026-04-27  5:13     ` K Prateek Nayak
2026-04-27  8:35       ` Vincent Guittot
2026-04-27 16:01         ` Andrea Righi
2026-04-27 17:26           ` Vincent Guittot
2026-04-23  7:36 ` [PATCH 5/5] sched/fair: Make asym CPU capacity idle rank values self-documenting Andrea Righi
2026-04-24  4:29   ` K Prateek Nayak
2026-04-24  5:19     ` Andrea Righi
2026-04-24 12:34       ` Vincent Guittot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aeukvYcx0yLaPvps@gpd4 \
    --to=arighi@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=bsegall@google.com \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=fabecassis@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=juri.lelli@redhat.com \
    --cc=kobak@nvidia.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.