lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <52b5b07d-89ee-4266-a229-ce9a8c6f8cb1@amd.com>
Date: Fri, 23 Jan 2026 17:54:30 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Peter Zijlstra <peterz@...radead.org>, Mario Roy <marioeroy@...il.com>
CC: Chris Mason <clm@...a.com>, Joseph Salisbury
	<joseph.salisbury@...cle.com>, Adam Li <adamli@...amperecomputing.com>,
	"Hazem Mohamed Abuelfotoh" <abuehaze@...zon.com>, Josh Don
	<joshdon@...gle.com>, <mingo@...hat.com>, <juri.lelli@...hat.com>,
	<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
	<rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
	<vschneid@...hat.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] sched/fair: Proportional newidle balance

Hello Peter,

On 1/23/2026 4:33 PM, Peter Zijlstra wrote:
> On Fri, Jan 23, 2026 at 11:50:46AM +0100, Peter Zijlstra wrote:
>> On Sun, Jan 18, 2026 at 03:46:22PM -0500, Mario Roy wrote:
>>> The patch "Proportional newidle balance" introduced a regression
>>> with Linux 6.12.65 and 6.18.5. There is noticeable regression with
>>> easyWave testing. [1]
>>>
>>> The CPU is AMD Threadripper 9960X CPU (24/48). I followed the source
>>> to install easyWave [2]. That is fetching the two tar.gz archives.
>>
>> What is the actual configuration of that chip? Is it like 3*8 or 4*6
>> (CCX wise). A quick google couldn't find me the answer :/
> 
> Obviously I found it right after sending this. It's a 4x6 config.
> Meaning it needs newidle to balance between those 4 domains.
> 
> Pratheek -- are you guys still considering that SIS_NODE thing? That
> worked really well for workstation chips, but there were some issues on
> Epyc or so.

SIS_NODE was really turned out to be a trade-off between search
time vs search opportunity, especially when the system was heavily
overloaded.

Let me rebase those old patches and give it a spin over the weekend
on a couple of those large machines (128C/256T and 192C/384T per
socket) to see the damage. I'll update here by Tuesday or post out
a series if I see the situation having changed on the recent
kernels - some benchmarks had a completely different bottleneck
there when we looked closer last.

> 
>>> #!/bin/bash
>>> # CXXFLAGS="-O3 $CXXFLAGS" ./configure
>>> # make -j8
>>>
>>> trap 'rm -f *.ssh *.idx *.log *.sshmax *.time' EXIT
>>>
>>> OMP_NUM_THREADS=48 ./src/easywave \
>>>   -grid examples/e2Asean.grd -source examples/BengkuluSept2007.flt \
>>>   -time 1200
>>>
>>>
>>> Before results with CachyOS 6.12.63-2 and 6.18.3-2 kernels.

I'll go look at the benchmark too to see if I can reproduce on my end
and get some stats for these too. Thanks for bringing it to my notice.

-- 
Thanks and Regards,
Prateek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ