From: "Chen, Yu C" <yu.c.chen@intel.com>
To: K Prateek Nayak <kprateek.nayak@amd.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>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
"Ingo Molnar" <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 8/8] sched/fair: Simplify SIS_UTIL handling in select_idle_cpu()
Date: Sat, 14 Feb 2026 23:56:11 +0800 [thread overview]
Message-ID: <5d6ca759-e08a-4157-87ad-a32345685879@intel.com> (raw)
In-Reply-To: <20260120113246.27987-9-kprateek.nayak@amd.com>
On 1/20/2026 7:32 PM, K Prateek Nayak wrote:
> Use the "sd_llc" passed to select_idle_cpu() to obtain the
> "sd_llc_shared" instead of dereferencing the per-CPU variable.
>
> Since "sd->shared" is always reclaimed at the same time as "sd" via
> call_rcu() and update_top_cache_domain() always ensures a valid
> "sd->shared" assignment when "sd_llc" is present, "sd_llc->shared" can
> always be dereferenced without needing an additional check.
>
> While at it move the cpumask_and() operation after the SIS_UTIL bailout
> check to avoid unnecessarily computing the cpumask.
>
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> ---
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
I ran netperf, schbench, hackbench, stress-ng-context,
and stream on a platform with 384 CPUs and 6 nodes, and no
significant differences were observed. (Netperf is of the
greatest interest because SIS_UTIL had a substantial impact
on netperf when it was first introduced.) I suppose
sched/topology: Switch to assigning "sd->shared" from s_data
will have a new version, I'll look at it when it is posted.
netperf
baseline llc
Hmean-96pairs 119.86 ( 0.00%) 122.21 ( 1.96%)
Hmean-192pairs 56.48 ( 0.00%) 57.37 ( 1.57%)
Hmean-288pairs 78.27 ( 0.00%) 78.21 ( -0.08%)
Hmean-384pairs 62.69 ( 0.00%) 62.98 ( 0.47%)
thanks,
Chenyu
next prev parent reply other threads:[~2026-02-14 15:56 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
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 [this message]
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=5d6ca759-e08a-4157-87ad-a32345685879@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.