[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251030093013.GI4067720@noisy.programming.kicks-ass.net>
Date: Thu, 30 Oct 2025 10:30:13 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Adam Li <adamli@...amperecomputing.com>
Cc: Joseph Salisbury <joseph.salisbury@...cle.com>,
	Chris Mason <clm@...a.com>, clm@...com,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Juri Lelli <juri.lelli@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	dietmar.eggemann@....com, Steven Rostedt <rostedt@...dmis.org>,
	bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [External] : Re: [REGRESSION][v6.17-rc1]sched/fair: Bump
 sd->max_newidle_lb_cost when newidle balance fails
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.
Powered by blists - more mailing lists
 
