linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	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@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>, Mel Gorman <mgorman@suse.de>,
	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 2/2] powerpc/smp: Disable ACCT_STEAL for shared LPARs
Date: Tue, 28 Oct 2025 16:12:55 +0530	[thread overview]
Message-ID: <20251028104255.1892485-2-srikar@linux.ibm.com> (raw)
In-Reply-To: <20251028104255.1892485-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 the
ACCT_STEAL scheduling feature 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.02358   (0.0346247)
72                 1         (0.0387066)    1.11729   (0.0215052)
96                 1         (0.013317)     1.07751   (0.014656)
128                1         (0.028087)     1.0585    (0.0173575)
144                1         (0.0103478)    1.11785   (0.0472121)
192                1         (0.0164666)    1.0212    (0.0226717)
256                1         (0.0241208)    0.969056  (0.0169747)
288                1         (0.0121516)    0.971862  (0.0190453)

scaled perf stats for 72 thread case.
event         baseline  +patch
cycles        1         1.16475
instructions  1         1.13198
cs            1         0.914774
migrations    1         0.116058
faults        1         0.94104
cache-misses  1         1.75184

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)    0.985758  (0.0204456)
72                 1         (0.0308503)    1.0288    (0.065893)
96                 1         (0.0500514)    1.07178   (0.0376889)
128                1         (0.0602872)    0.986705  (0.0467856)
144                1         (0.0843502)    1.04157   (0.0626338)
192                1         (0.0255402)    1.03327   (0.0975257)
256                1         (0.00653372)   1.04572   (0.00576901)
288                1         (0.00318369)   1.04578   (0.0115398)

Signed-off-by: Srikar Dronamraju <srikar@linux.ibm.com>
---
 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..d80053f0a05e 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);
+		steal_updates_cpu_capacity(false);
+	}
 
 #ifdef CONFIG_SCHED_SMT
 	if (has_big_cores) {
-- 
2.47.3



  reply	other threads:[~2025-10-28 10:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 10:42 [PATCH 1/2] sched: Feature to decide if steal should update CPU capacity Srikar Dronamraju
2025-10-28 10:42 ` Srikar Dronamraju [this message]
2025-10-28 11:18 ` Peter Zijlstra
2025-10-28 11:42   ` Srikar Dronamraju
2025-10-28 15:05 ` Shrikanth Hegde
2025-10-29  6:08   ` K Prateek Nayak

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=20251028104255.1892485-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@redhat.com \
    --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).