linux-kernel - Re: [PATCH 4/4] sched/fair: Proportional newidle balance

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d162947f-e490-4b6b-aee3-458185001e95@amazon.com>
Date: Wed, 4 Feb 2026 13:59:24 +0000
From: "Mohamed Abuelfotoh, Hazem" <abuehaze@...zon.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Mario Roy <marioeroy@...il.com>, Chris Mason <clm@...a.com>, "Joseph
 Salisbury" <joseph.salisbury@...cle.com>, Adam Li
	<adamli@...amperecomputing.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

On 04/02/2026 13:27, Peter Zijlstra wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On Wed, Feb 04, 2026 at 12:45:41PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> 
>> Version           | Benchmark name   | SUT EC2 Instance| diff %
>> v6.12.66          | postgresql       | c7a.4xlarge     | -4.0%
>> v6.12.66          | nginx_lb         | c7a.4xlarge     | -5.0%
>> v6.12.66          | memcached        | c7a.4xlarge     | -11.0%
>> v6.12.66_proposed | postgresql       | c7a.4xlarge     | -4.0%
>> v6.12.66_proposed | nginx_lb         | c7a.4xlarge     | -5.0%
>> v6.12.66_proposed | memcached        | c7a.4xlarge     | -13.0%
> 
> *sigh*, that actually made it worse for memcached :/ I'm not familiar
> with the memcached benchmark, is this something I can run on a single
> machine, or does it require high speed networking and 2 machines?

Yup that's true it's slightly worse on memcached with the proposed fix:( 
The memcached benchmark is kind of multi-layer test where you need at at 
least 2 client machines and 1 server machine and 1 machine as a test 
coordinator. The server VM is able to achieve 12.5 Gbps of network 
bandwidth and the client each one is able to achieve 30 Gbps so I think 
it will be tricky and likely impossible to reproduce this on a single 
machine. I will try to come-up with standalone reproduction steps that 
can be used to investigate this memcached regression. Meanwhile we will 
share the fio regression reproduction steps that I mentioned in my 
previous update. This should be much simpler in steps and can be done on 
a single machine.