From: Srikar Dronamraju <srikar@linux.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, Ben Segall <bsegall@google.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ingo Molnar <mingo@kernel.org>,
Juri Lelli <juri.lelli@redhat.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Mel Gorman <mgorman@suse.de>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Valentin Schneider <vschneid@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Srikar Dronamraju <srikar@linux.ibm.com>
Subject: [PATCH v2 2/2] powerpc/smp: Disable steal from updating CPU capacity
Date: Wed, 29 Oct 2025 11:37:57 +0530 [thread overview]
Message-ID: <20251029060757.2007601-2-srikar@linux.ibm.com> (raw)
In-Reply-To: <20251029060757.2007601-1-srikar@linux.ibm.com>
In a shared LPAR with SMT enabled, it has been observed that when a CPU
experiences steal time, it can trigger task migrations between sibling
CPUs. The idle CPU pulls a runnable task from its sibling that is
impacted by steal, making the previously busy CPU go idle. This reversal
can repeat continuously, resulting in ping-pong behavior between SMT
siblings.
To avoid migrations solely triggered by steal time, disable steal from
updating CPU capacity when running in shared processor mode.
lparstat
System Configuration
type=Shared mode=Uncapped smt=8 lcpu=72 mem=2139693696 kB cpus=64 ent=24.00
Noise case: (Ebizzy on 2 LPARs with similar configuration as above)
nr-ebizzy-threads baseline std-deviation +patch std-deviation
36 1 (0.0345589) 1.01073 (0.0411082)
72 1 (0.0387066) 1.12867 (0.029486)
96 1 (0.013317) 1.05755 (0.0118292)
128 1 (0.028087) 1.04193 (0.027159)
144 1 (0.0103478) 1.07522 (0.0265476)
192 1 (0.0164666) 1.02177 (0.0164088)
256 1 (0.0241208) 0.977572 (0.0310648)
288 1 (0.0121516) 0.97529 (0.0263536)
384 1 (0.0128001) 0.967025 (0.0207603)
512 1 (0.0113173) 1.00975 (0.00753263)
576 1 (0.0126021) 1.01087 (0.0054196)
864 1 (0.0109194) 1.00369 (0.00987092)
1024 1 (0.0121474) 1.00338 (0.0122591)
1152 1 (0.013801) 1.0097 (0.0150391)
scaled perf stats for 72 thread case.
event baseline +patch
cycles 1 1.16993
instructions 1 1.14435
cs 1 0.913554
migrations 1 0.110884
faults 1 1.0005
cache-misses 1 1.68619
Observations:
- We see a drop in context-switches and migrations resulting in an
improvement in the records per second.
No-noise case: (Ebizzy on 1 LPARs with other LPAR being idle)
nr-ebizzy-threads baseline std-deviation +patch std-deviation
36 1 (0.0451482) 1.01243 (0.0434088)
72 1 (0.0308503) 1.06175 (0.0373877)
96 1 (0.0500514) 1.13143 (0.0718754)
128 1 (0.0602872) 1.09909 (0.0375227)
144 1 (0.0843502) 1.07494 (0.0240824)
192 1 (0.0255402) 0.992734 (0.0615166)
256 1 (0.00653372) 0.982841 (0.00751558)
288 1 (0.00318369) 0.99093 (0.00960287)
384 1 (0.00272681) 0.974312 (0.0112133)
512 1 (0.00528486) 0.981207 (0.0125443)
576 1 (0.00491385) 0.992027 (0.0104948)
864 1 (0.0087057) 0.994927 (0.0143434)
1024 1 (0.010002) 0.992463 (0.00429322)
1152 1 (0.00720965) 1.00393 (0.012553)
Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
---
Changelog v1->v2:
v1: https://lkml.kernel.org/r/20251028104255.1892485-2-srikar@linux.ibm.com
Peter suggested to use static branch instead of sched feat
arch/powerpc/kernel/smp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 5ac7084eebc0..0f7fae0b4420 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1694,8 +1694,11 @@ static void __init build_sched_topology(void)
{
int i = 0;
- if (is_shared_processor() && has_big_cores)
- static_branch_enable(&splpar_asym_pack);
+ if (is_shared_processor()) {
+ if (has_big_cores)
+ static_branch_enable(&splpar_asym_pack);
+ sched_disable_steal_acct();
+ }
#ifdef CONFIG_SCHED_SMT
if (has_big_cores) {
--
2.47.3
next prev parent reply other threads:[~2025-10-29 6:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 6:07 [PATCH v2 1/2] sched/core: Option if steal should update CPU capacity Srikar Dronamraju
2025-10-29 6:07 ` Srikar Dronamraju [this message]
2025-10-29 7:43 ` [PATCH v2 2/2] powerpc/smp: Disable steal from updating " Vincent Guittot
2025-10-29 8:31 ` Srikar Dronamraju
2025-11-03 8:46 ` Vincent Guittot
2025-11-06 5:22 ` Srikar Dronamraju
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=20251029060757.2007601-2-srikar@linux.ibm.com \
--to=srikar@linux.ibm.com \
--cc=bsegall@google.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).