From: Peter Zijlstra <peterz@infradead.org>
To: Adam Li <adamli@os.amperecomputing.com>
Cc: Joseph Salisbury <joseph.salisbury@oracle.com>,
Chris Mason <clm@meta.com>,
clm@fb.com, Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
dietmar.eggemann@arm.com, Steven Rostedt <rostedt@goodmis.org>,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [External] : Re: [REGRESSION][v6.17-rc1]sched/fair: Bump sd->max_newidle_lb_cost when newidle balance fails
Date: Thu, 30 Oct 2025 10:30:13 +0100 [thread overview]
Message-ID: <20251030093013.GI4067720@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <2aa7380b-bebd-4bb9-8597-49e06d1dcc6d@os.amperecomputing.com>
Hi Adam,
On Thu, Oct 30, 2025 at 03:22:34PM +0800, Adam Li wrote:
> Commit 155213a2aed4 brings ~6% regression for SpecJBB critical-jOPS on
> AmpereOne server.
>
> Baseline: v6.17 kernel + patch. Compared with baseline:
> NI_TARGET +7%
> NI_SPARE -3%
> NI_RUNNABLE -4%
> NI_RANDOM -3%
>
> So NI_TARGET reverts the performance regression.
> The other options brings more regression for SpecJBB.
Excellent, how does NI_TARGET+NI_RANDOM work for you? Like Chris, I
found that the schbench workload was really suffering from doing too
many idle balance attempts that weren't really working out.
NI_RANDOM reduces the number of newidle balances based on the success
ratio. Eg. if you have successful balancing 25% of the time, it will do
1 in 4 balances and count a successful balance as 4 to keep the
accounting straight.
So workloads with a high success rate will keep newidle balance calls
frequent, while workloads with a low success rate (like schbench) will
greatly reduce the number of calls.
next prev parent reply other threads:[~2025-10-30 9:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 20:23 [REGRESSION][v6.17-rc1]sched/fair: Bump sd->max_newidle_lb_cost when newidle balance fails Joseph Salisbury
2025-10-06 21:23 ` Chris Mason
2025-10-07 11:34 ` Peter Zijlstra
2025-10-10 1:04 ` [External] : " Joseph Salisbury
2025-10-10 17:09 ` Peter Zijlstra
2025-10-17 17:01 ` Joseph Salisbury
2025-10-30 7:29 ` Adam Li
2025-10-31 21:16 ` [External] : " Joseph Salisbury
2025-11-04 18:11 ` Joseph Salisbury
2025-10-30 7:22 ` Adam Li
2025-10-30 9:30 ` Peter Zijlstra [this message]
2025-10-30 20:53 ` Dietmar Eggemann
2025-10-31 2:46 ` Adam Li
2025-10-10 1:14 ` Joseph Salisbury
2025-10-07 20:22 ` [External] : " Joseph Salisbury
2025-10-10 13:09 ` Hazem Mohamed Abuelfotoh
2025-10-27 18:36 ` Josh Don
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=20251030093013.GI4067720@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=adamli@os.amperecomputing.com \
--cc=bsegall@google.com \
--cc=clm@fb.com \
--cc=clm@meta.com \
--cc=dietmar.eggemann@arm.com \
--cc=joseph.salisbury@oracle.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--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