From: Andrea Righi <arighi@nvidia.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
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>,
Joel Fernandes <joelagnelf@nvidia.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection
Date: Thu, 19 Mar 2026 12:11:53 +0100 [thread overview]
Message-ID: <abvZ-QQvBbzNvJ5L@gpd4> (raw)
In-Reply-To: <CAKfTPtA5N6m1mCBuCD8n6wqfd6r5-iq3=xamKBWp-kfsrR3nhg@mail.gmail.com>
Hi Vincent,
On Thu, Mar 19, 2026 at 08:17:06AM +0100, Vincent Guittot wrote:
> On Wed, 18 Mar 2026 at 11:31, Andrea Righi <arighi@nvidia.com> wrote:
> >
> > Hi Vincent,
> >
> > On Wed, Mar 18, 2026 at 10:41:15AM +0100, Vincent Guittot wrote:
> > > On Wed, 18 Mar 2026 at 10:22, Andrea Righi <arighi@nvidia.com> wrote:
> > > >
> > > > On systems with asymmetric CPU capacity (e.g., ACPI/CPPC reporting
> > > > different per-core frequencies), the wakeup path uses
> > > > select_idle_capacity() and prioritizes idle CPUs with higher capacity
> > > > for better task placement. However, when those CPUs belong to SMT cores,
> > >
> > > Interesting, which kind of system has both SMT and SD_ASYM_CPUCAPACITY
> > > ? I thought both were never set simultaneously and SD_ASYM_PACKING was
> > > used for system involving SMT like x86
> >
> > It's an NVIDIA platform (not publicly available yet), where the firmware
> > exposes different CPU capacities and has SMT enabled, so both
> > SD_ASYM_CPUCAPACITY and SMT are present. I'm not sure whether the final
> > firmware release will keep this exact configuration (there's a good chance
> > it will), so I'm targeting it to be prepared.
>
> That's probably not the only place where SD_ASYM_CPUCAPACITY will fail
> with SMT. The misfit is another place as an example
Yeah, that's right, with SD_ASYM_CPUCAPACITY + SMT when a misfit task is
moved from a "small" CPU to a "big" CPU, if the big CPU has a busy sibling,
its effective capacity is much lower than its nominal capacity.
Maybe when SMT is active, we could allow pulling a misfit task only when
dst_cpu is on a fully idle core. That's a simple change, I'll run some
tests with this, but as you said there might be other places to fix as
well.
Thanks,
-Andrea
prev parent reply other threads:[~2026-03-19 11:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 9:22 [PATCH] sched/fair: Prefer fully-idle SMT cores in asym-capacity idle selection Andrea Righi
2026-03-18 9:41 ` Vincent Guittot
2026-03-18 10:31 ` Andrea Righi
2026-03-18 15:43 ` Christian Loehle
2026-03-18 17:09 ` Andrea Righi
2026-03-19 7:20 ` Vincent Guittot
2026-03-19 8:45 ` Andrea Righi
2026-03-19 11:58 ` Christian Loehle
2026-03-19 14:00 ` Andrea Righi
2026-03-19 7:17 ` Vincent Guittot
2026-03-19 11:11 ` Andrea Righi [this message]
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=abvZ-QQvBbzNvJ5L@gpd4 \
--to=arighi@nvidia.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--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.