From: "Chen, Yu C" <yu.c.chen@intel.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/8] sched/topology: Switch to assigning "sd->shared" from s_data
Date: Sat, 14 Feb 2026 11:04:08 +0800 [thread overview]
Message-ID: <cc74535f-5794-4228-958e-ebe579b950cb@intel.com> (raw)
In-Reply-To: <xhsmh343e43fd.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
On 2/6/2026 5:38 PM, Valentin Schneider wrote:
> On 06/02/26 10:50, K Prateek Nayak wrote:
>> Hello Valentin,
>>
>> On 2/5/2026 10:23 PM, Valentin Schneider wrote:
>>> On 20/01/26 11:32, K Prateek Nayak wrote:
[ ... ]
>
> AIUI we currently write sd->imb_numa_nr for all SD's, but it's only useful
> for the SD_NUMA ones... How about the lightly tested:
> ---
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index afb2c26efb4e5..03db45658f6bd 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -2575,6 +2575,51 @@ static bool topology_span_sane(const struct cpumask *cpu_map)
> return true;
> }
>
> +static inline void adjust_numa_imbalance(struct sched_domain *sd_llc,
> + unsigned int *imb, unsigned int *imb_span)
> +{
> + /*
> + * For a single LLC per node, allow an
> + * imbalance up to 12.5% of the node. This is
> + * arbitrary cutoff based two factors -- SMT and
> + * memory channels. For SMT-2, the intent is to
> + * avoid premature sharing of HT resources but
> + * SMT-4 or SMT-8 *may* benefit from a different
> + * cutoff. For memory channels, this is a very
> + * rough estimate of how many channels may be
> + * active and is based on recent CPUs with
> + * many cores.
> + *
> + * For multiple LLCs, allow an imbalance
> + * until multiple tasks would share an LLC
> + * on one node while LLCs on another node
> + * remain idle. This assumes that there are
> + * enough logical CPUs per LLC to avoid SMT
> + * factors and that there is a correlation
> + * between LLCs and memory channels.
> + */
> + struct sched_domain *top_p;
> + unsigned int nr_llcs;
> +
> + WARN_ON(!(sd_llc->flags & SD_SHARE_LLC));
> + WARN_ON(!sd_llc->parent);
> +
> + nr_llcs = sd_llc->parent->span_weight / sd_llc->span_weight;
> + if (nr_llcs == 1)
> + *imb = sd_llc->parent->span_weight >> 3;
> + else
> + *imb = nr_llcs;
> + *imb = max(1U, *imb);
> + sd_llc->parent->imb_numa_nr = *imb;
> +
> + /* Set span based on the first NUMA domain. */
> + top_p = sd_llc->parent->parent;
> + while (top_p && !(top_p->flags & SD_NUMA)) {
> + top_p = top_p->parent;
> + }
> + *imb_span = top_p ? top_p->span_weight : sd_llc->parent->span_weight;
> +}
> +
> /*
> * Build sched domains for a given set of CPUs and attach the sched domains
> * to the individual CPUs
> @@ -2640,63 +2685,30 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
> unsigned int imb = 0;
> unsigned int imb_span = 1;
>
> - for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) {
> - struct sched_domain *parent = sd->parent;
> -
> - /* Topmost SD_SHARE_LLC domain. */
> - if ((sd->flags & SD_SHARE_LLC) &&
> - (!parent || !(parent->flags & SD_SHARE_LLC))) {
> - int sd_id = cpumask_first(sched_domain_span(sd));
> - struct sched_domain *top_p;
> - unsigned int nr_llcs;
> -
> - sd->shared = *per_cpu_ptr(d.sds, sd_id);
> - atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight);
> - atomic_inc(&sd->shared->ref);
> -
> - /* No SD_NUMA domains. */
> - if (!parent)
> - break;
> -
> - /*
> - * For a single LLC per node, allow an
> - * imbalance up to 12.5% of the node. This is
> - * arbitrary cutoff based two factors -- SMT and
> - * memory channels. For SMT-2, the intent is to
> - * avoid premature sharing of HT resources but
> - * SMT-4 or SMT-8 *may* benefit from a different
> - * cutoff. For memory channels, this is a very
> - * rough estimate of how many channels may be
> - * active and is based on recent CPUs with
> - * many cores.
> - *
> - * For multiple LLCs, allow an imbalance
> - * until multiple tasks would share an LLC
> - * on one node while LLCs on another node
> - * remain idle. This assumes that there are
> - * enough logical CPUs per LLC to avoid SMT
> - * factors and that there is a correlation
> - * between LLCs and memory channels.
> - */
> - nr_llcs = parent->span_weight / sd->span_weight;
> - if (nr_llcs == 1)
> - imb = sd->span_weight >> 3;
> - else
> - imb = nr_llcs;
> - imb = max(1U, imb);
> - sd->imb_numa_nr = imb;
> -
> - /* Set span based on the first NUMA domain. */
> - top_p = parent;
> - while (top_p && !(top_p->flags & SD_NUMA)) {
> - top_p = top_p->parent;
> - }
> - imb_span = top_p ? top_p->span_weight : parent->span_weight;
> - } else {
> - int factor = max(1U, (sd->span_weight / imb_span));
> + sd = *per_cpu_ptr(d.sd, i);
might be
if (!sd)
continue;
otherwise sd->flags below might cause NULL pointer exception.
thanks,
Chenyu
next prev parent reply other threads:[~2026-02-14 3:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 11:32 [PATCH v3 0/8] sched/topology: Optimize sd->shared allocation K Prateek Nayak
2026-01-20 11:32 ` [PATCH v3 1/8] sched/topology: Compute sd_weight considering cpuset partitions K Prateek Nayak
2026-01-21 14:45 ` Chen, Yu C
2026-01-21 15:42 ` Shrikanth Hegde
2026-01-22 2:51 ` K Prateek Nayak
2026-02-05 16:53 ` Valentin Schneider
2026-01-20 11:32 ` [PATCH v3 2/8] sched/topology: Allocate per-CPU sched_domain_shared in s_data K Prateek Nayak
2026-01-21 15:17 ` Chen, Yu C
2026-02-05 16:53 ` Valentin Schneider
2026-01-20 11:32 ` [PATCH v3 3/8] sched/topology: Switch to assigning "sd->shared" from s_data K Prateek Nayak
2026-01-21 15:26 ` Chen, Yu C
2026-01-22 2:49 ` K Prateek Nayak
2026-01-22 8:12 ` Shrikanth Hegde
2026-01-22 8:36 ` K Prateek Nayak
2026-01-23 4:08 ` Shrikanth Hegde
2026-01-23 4:53 ` K Prateek Nayak
2026-02-05 16:53 ` Valentin Schneider
2026-02-06 5:20 ` K Prateek Nayak
2026-02-06 9:38 ` Valentin Schneider
2026-02-14 3:04 ` Chen, Yu C [this message]
2026-02-16 3:50 ` K Prateek Nayak
2026-02-14 2:59 ` Chen, Yu C
2026-01-20 11:32 ` [PATCH v3 4/8] sched/topology: Remove sched_domain_shared allocation with sd_data K Prateek Nayak
2026-02-05 16:53 ` Valentin Schneider
2026-01-20 11:32 ` [PATCH v3 5/8] sched/core: Check for rcu_read_lock_any_held() in idle_get_state() K Prateek Nayak
2026-01-20 11:32 ` [PATCH v3 6/8] sched/fair: Remove superfluous rcu_read_lock() in the wakeup path K Prateek Nayak
2026-01-20 11:32 ` [PATCH v3 7/8] sched/fair: Simplify the entry condition for update_idle_cpu_scan() K Prateek Nayak
2026-02-14 15:41 ` Chen, Yu C
2026-01-20 11:32 ` [PATCH v3 8/8] sched/fair: Simplify SIS_UTIL handling in select_idle_cpu() K Prateek Nayak
2026-01-23 6:06 ` Shrikanth Hegde
2026-01-23 6:27 ` K Prateek Nayak
2026-01-23 7:14 ` Shrikanth Hegde
2026-02-14 15:56 ` Chen, Yu C
2026-01-21 16:16 ` [PATCH v3 0/8] sched/topology: Optimize sd->shared allocation Peter Zijlstra
2026-01-22 2:56 ` K Prateek Nayak
2026-01-23 9:54 ` Peter Zijlstra
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=cc74535f-5794-4228-958e-ebe579b950cb@intel.com \
--to=yu.c.chen@intel.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gautham.shenoy@amd.com \
--cc=juri.lelli@redhat.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.