mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: Andrea Righi <arighi@nvidia.com>
Cc: 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>,
	Srikar Dronamraju <srikar@linux.ibm.com>,
	Phil Auld <pauld@redhat.com>, Breno Leitao <leitao@debian.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Lee Trager <ltrager@nvidia.com>, Vikram Sethi <vsethi@nvidia.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH 2/2] sched/topology: Add asymmetric SMT packing override
Date: Fri, 18 Sep 2026 19:44:25 +0530	[thread overview]
Message-ID: <97c99014-d488-4468-896a-decf55636fa5@linux.ibm.com> (raw)
In-Reply-To: <20260917140707.3807229-3-arighi@nvidia.com>

Hi Andrea,

On 9/17/26 7:35 PM, Andrea Righi wrote:
> Architectures can use SD_ASYM_PACKING to describe preferred CPU ordering
> at the SMT scheduling domain. Some systems benefit from the same policy,
> but their firmware cannot currently describe the preference. Inferring
> it from the CPU model would embed a platform-specific policy in the
> kernel.
> 
> Add the sched_smt_asym_packing boot option to override SD_ASYM_PACKING
> at the SMT level. Accept auto, on and off. Auto preserves the
> architecture-provided topology and is also the default when the option
> is absent. On and off force the flag without changing asymmetric packing
> at higher topology levels.
> 
> Apply the override centrally to domains with SD_SHARE_CPUCAPACITY so it
> also covers architectures with custom SMT topology callbacks, including
> powerpc. When forced on, priority remains defined by
> arch_asym_cpu_priority(). The weak default prefers lower-numbered
> logical CPUs, while architecture overrides remain authoritative.
> Siblings with equal priorities remain unordered.
> 

Wasn't this a temporary solution you wanted until the firmware changes are
sorted out? or something changed in between?

If yes, could you please capture that in changelog or in comment.

> Signed-off-by: Andrea Righi <arighi@nvidia.com>
> ---
>   .../admin-guide/kernel-parameters.txt         | 11 +++++
>   kernel/sched/topology.c                       | 49 +++++++++++++++++++
>   2 files changed, 60 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 33cd30996e47e..36c3b2e563441 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -6799,6 +6799,17 @@ Kernel parameters
>   			solution to mutex-based priority inversion.
>   			Format: <bool>
>   
> +	sched_smt_asym_packing= [KNL,SMP]
> +			Override asymmetric packing at the SMT scheduling domain.
> +			Format: { auto | on | off }
> +			auto: Preserve the architecture default. This is the
> +			default when the option is omitted.
> +			on: Force asymmetric packing at the SMT scheduling domain.
> +			Idle CPU selection prefers siblings with a higher
> +			architecture-defined priority. Siblings with equal
> +			priorities remain unordered.
> +			off: Ignore SMT sibling priorities.
> +

Wasn't this option/parameter to come from arch specific file?

Isn't it going to be confusing for archs which don't benefit from asym packing at SMT,
but now there is kernel parameter to say on.

>   	sched_verbose	[KNL,EARLY] Enables verbose scheduler debug messages.
>   
>   	schedstats=	[KNL,X86] Enable or disable scheduled statistics.
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 0248227d983a7..cdfcecf673fd7 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -32,6 +32,46 @@ static int __init sched_debug_setup(char *str)
>   }
>   early_param("sched_verbose", sched_debug_setup);
>   
> +#ifdef CONFIG_SCHED_SMT
> +enum sched_smt_asym_packing_mode {
> +	SCHED_SMT_ASYM_PACKING_AUTO,
> +	SCHED_SMT_ASYM_PACKING_ON,
> +	SCHED_SMT_ASYM_PACKING_OFF,
> +	SCHED_SMT_ASYM_PACKING_NR,
> +};
> +
> +static enum sched_smt_asym_packing_mode sched_smt_asym_packing __read_mostly =
> +	SCHED_SMT_ASYM_PACKING_AUTO;
> +
> +static const char * const sched_smt_asym_packing_modes[SCHED_SMT_ASYM_PACKING_NR] = {
> +	[SCHED_SMT_ASYM_PACKING_AUTO]	= "auto",
> +	[SCHED_SMT_ASYM_PACKING_ON]	= "on",
> +	[SCHED_SMT_ASYM_PACKING_OFF]	= "off",
> +};
> +
> +static int __init sched_smt_asym_packing_parse(const char *str)
> +{
> +	for (int mode = 0; mode < SCHED_SMT_ASYM_PACKING_NR; mode++) {
> +		if (!strcmp(str, sched_smt_asym_packing_modes[mode]))
> +			return mode;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int __init setup_sched_smt_asym_packing(char *str)
> +{
> +	int mode = sched_smt_asym_packing_parse(str);
> +
> +	if (mode < 0)
> +		return 0;
> +
> +	sched_smt_asym_packing = mode;
> +	return 1;
> +}
> +__setup("sched_smt_asym_packing=", setup_sched_smt_asym_packing);
> +#endif
> +
>   static inline bool sched_debug(void)
>   {
>   	return sched_debug_verbose;
> @@ -1950,6 +1990,15 @@ sd_init(struct sched_domain_topology_level *tl,
>   	if (WARN_ONCE(sd_flags & ~TOPOLOGY_SD_FLAGS,
>   		      "wrong sd_flags in topology description\n"))
>   		sd_flags &= TOPOLOGY_SD_FLAGS;
> +#ifdef CONFIG_SCHED_SMT
> +	if (sd_flags & SD_SHARE_CPUCAPACITY) {
> +		if (sched_smt_asym_packing == SCHED_SMT_ASYM_PACKING_ON)
> +			sd_flags |= SD_ASYM_PACKING;
> +		else if (sched_smt_asym_packing ==
> +			 SCHED_SMT_ASYM_PACKING_OFF)
> +			sd_flags &= ~SD_ASYM_PACKING;
> +	}
> +#endif
>   	sd_flags |= asym_cpu_capacity_classify(sd_span, cpu_map);
>   
>   	*sd = (struct sched_domain){


  reply	other threads:[~2026-09-18 14:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 14:05 [PATCH v6 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-17 14:05 ` [PATCH 1/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-17 16:55   ` Kayra Cizmeci
2026-09-18  6:28     ` Kayra Cizmeci
2026-09-18 15:58   ` Vincent Guittot
2026-09-17 14:05 ` [PATCH 2/2] sched/topology: Add asymmetric SMT packing override Andrea Righi
2026-09-18 14:14   ` Shrikanth Hegde [this message]
2026-09-18 16:03     ` Vincent Guittot
2026-09-18 18:27       ` Andrea Righi
2026-09-18 18:24     ` 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=97c99014-d488-4468-896a-decf55636fa5@linux.ibm.com \
    --to=sshegde@linux.ibm.com \
    --cc=arighi@nvidia.com \
    --cc=bsegall@google.com \
    --cc=christian.loehle@arm.com \
    --cc=corbet@lwn.net \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=leitao@debian.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltrager@nvidia.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=skhan@linuxfoundation.org \
    --cc=srikar@linux.ibm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=vsethi@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®