From: Srikar Dronamraju <srikar@linux.ibm.com>
To: Andrea Righi <arighi@nvidia.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.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>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Mark Rutland <mark.rutland@arm.com>,
Christian Loehle <christian.loehle@arm.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Phil Auld <pauld@redhat.com>, Breno Leitao <leitao@debian.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection
Date: Tue, 8 Sep 2026 11:07:20 +0530 [thread overview]
Message-ID: <ap-fELvfw5w51vbG@linux.ibm.com> (raw)
In-Reply-To: <20260904091838.3617894-3-arighi@nvidia.com>
* Andrea Righi <arighi@nvidia.com> [2026-09-04 11:18:05]:
Hi Andrea,
> POWER7 and NVIDIA Olympus use SD_ASYM_PACKING at the shared-capacity
> SMT level to order hardware threads. Idle CPU selection does not consult
> that order, so a task can wake on an arbitrary sibling and remain there
> until load balancing corrects the placement. On these systems, that
> initial choice can prevent the core from entering its preferred
> lower-thread resource mode and cause a large and persistent performance
> loss.
>
> When idle selection finds an available CPU in an SMT core, choose the
> highest-priority available sibling. On SMT2 Olympus this only changes
> selection on fully idle cores. A partially idle core has only one
> available CPU. On wider SMT systems such as POWER7, it also fills
> available siblings in priority order while the core is partially busy.
>
Don't we need changes in the slow path too?
Something like this?
https://lore.kernel.org/all/20251204175405.1511340-2-srikar@linux.ibm.com/T/#u
> Apply the preference to idle-core and idle-CPU scans,
> asymmetric-capacity scans, and the target, previous, and recently-used
> CPU fast paths. Inspect the lowest scheduling domain directly, but
> require both CPUs to share its span because isolcpus can split hardware
> siblings across scheduling domains.
>
> Keep physical-core capacity selection independent from SMT sibling
> ordering. SD_ASYM_CPUCAPACITY first selects among cores with different
> maximum capacities, then SD_ASYM_PACKING selects the preferred available
> sibling inside the chosen core, whose siblings continue to share equal
> capacity.
>
> Signed-off-by: Andrea Righi <arighi@nvidia.com>
> ---
> kernel/sched/fair.c | 79 ++++++++++++++++++++++++++++++++++++-----
> kernel/sched/sched.h | 6 ++++
> kernel/sched/topology.c | 36 +++++++++++++++++++
> 3 files changed, 112 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index b8bd308c2d5b1..ff9a7b1fcbe7f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8587,6 +8587,63 @@ static inline bool test_idle_cores(int cpu)
> return false;
> }
>
> +/*
> + * Return true when @cpu has a higher asymmetric-packing priority than
> + * @other in their shared SMT scheduling domain.
> + */
> +static bool sched_smt_asym_prefer(int cpu, int other)
> +{
> + struct sched_domain *sd = rcu_dereference_all(cpu_rq(cpu)->sd);
> +
> + if (!sd)
> + return false;
> +
> + if (!(sd->flags & SD_SHARE_CPUCAPACITY) ||
> + !(sd->flags & SD_ASYM_PACKING))
> + return false;
> +
> + if (!cpumask_test_cpu(other, sched_domain_span(sd)))
> + return false;
> +
> + return sched_asym_prefer(cpu, other);
> +}
> +
> +/*
> + * Return the highest-priority available CPU in @cpu's SMT core that is also in @cpus.
> + */
> +static int __select_idle_smt_cpu(struct task_struct *p, int cpu, const struct cpumask *cpus)
> +{
> + int best = cpu;
> + int sibling;
> +
> + for_each_cpu_and(sibling, cpu_smt_mask(cpu), cpus) {
> + if (sibling == best || !choose_idle_cpu(sibling, p))
> + continue;
> +
> + if (sched_smt_asym_prefer(sibling, best))
> + best = sibling;
> + }
> +
> + return best;
> +}
> +
> +static inline int
> +select_idle_smt_cpu(struct task_struct *p, int cpu, const struct cpumask *cpus)
> +{
> + if (!sched_smt_asym_active())
> + return cpu;
> +
> + return __select_idle_smt_cpu(p, cpu, cpus);
Nit: I see __select_idle_smt_cpu called only here.
Cant we fold __select_idle_smt_cpu() here itself.
> +}
> +
> +/*
> + * Redirect an available SMT CPU to a higher-priority available sibling allowed by task affinity.
> + */
> +static inline int select_idle_smt_priority(struct task_struct *p, int cpu)
> +{
> + return select_idle_smt_cpu(p, cpu, p->cpus_ptr);
> +}
> +
nit: Can we also replace select_idle_smt_priority with select_idle_smt_cpu()
itself.
Otherwise looks good to me
Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2026-09-08 5:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 9:18 [PATCH v2 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-04 9:18 ` [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores Andrea Righi
2026-09-04 9:18 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-07 3:57 ` K Prateek Nayak
2026-09-07 9:11 ` Andrea Righi
2026-09-07 9:40 ` K Prateek Nayak
2026-09-07 9:50 ` Andrea Righi
2026-09-07 16:48 ` Shrikanth Hegde
2026-09-08 5:37 ` Srikar Dronamraju [this message]
2026-09-08 6:12 ` Andrea Righi
-- strict thread matches above, loose matches on Subject: below --
2026-09-09 6:26 [PATCH v5 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-09 6:26 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-11 14:11 ` Dietmar Eggemann
2026-09-11 22:34 ` Andrea Righi
2026-09-08 8:23 [PATCH v4 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-08 8:23 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-08 19:40 ` K Prateek Nayak
2026-09-08 20:49 ` Andrea Righi
2026-09-09 6:32 ` K Prateek Nayak
2026-09-09 14:42 ` Vincent Guittot
2026-09-09 15:18 ` Andrea Righi
2026-09-09 15:42 ` Vincent Guittot
2026-09-09 16:22 ` Andrea Righi
2026-09-07 16:30 [PATCH v3 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-07 16:30 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-08-31 18:10 [PATCH 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-08-31 18:10 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-03 10:59 ` Dietmar Eggemann
2026-09-04 5:59 ` Andrea Righi
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=ap-fELvfw5w51vbG@linux.ibm.com \
--to=srikar@linux.ibm.com \
--cc=arighi@nvidia.com \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=christian.loehle@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sshegde@linux.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@kernel.org \
/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.