linux-kernel - Re: EEVDF regression still exists

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: <82DC7187-7CED-4285-85FC-7181688CD873@amazon.com>
Date: Tue, 29 Apr 2025 22:06:40 +0000
From: "Prundeanu, Cristian" <cpru@...zon.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: K Prateek Nayak <kprateek.nayak@....com>, "Mohamed Abuelfotoh, Hazem"
	<abuehaze@...zon.com>, "Saidi, Ali" <alisaidi@...zon.com>, "Benjamin
 Herrenschmidt" <benh@...nel.crashing.org>, "Blake, Geoff"
	<blakgeof@...zon.com>, "Csoma, Csaba" <csabac@...zon.com>, "Doebel, Bjoern"
	<doebel@...zon.de>, Gautham Shenoy <gautham.shenoy@....com>, Swapnil Sapkal
	<swapnil.sapkal@....com>, Joseph Salisbury <joseph.salisbury@...cle.com>,
	Dietmar Eggemann <dietmar.eggemann@....com>, Ingo Molnar <mingo@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>, Borislav Petkov
	<bp@...en8.de>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-tip-commits@...r.kernel.org"
	<linux-tip-commits@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: EEVDF regression still exists

On 2025-04-29, 16:57, "Peter Zijlstra" <peterz@...radead.org <mailto:peterz@...radead.org>> wrote:

>> Here are the latest results for the EEVDF impact on database workloads.
>> The regression introduced in kernel 6.6 still persists and doesn't look
>> like it is improving.
>
> Well, I was under the impression it had actually been solved :-(
>
> My understanding from the last round was that Prateek and co had it
> sorted -- with the caveat being that you had to stick SCHED_BATCH in at
> the right place in MySQL start scripts or somesuch.

The statement in the previous thread [1] was that using SCHED_BATCH improves 
performance over default. While that still holds true, it is also equally true
about using SCHED_BATCH on kernel 6.5.

So, when we compare 6.5 with recent kernels, both using SCHED_BATCH, the
regression is still visible. (Previously, we only compared SCHED_BATCH with 
6.5 default, leading to the wrong conclusion that it's a fix).

[1] https://lore.kernel.org/all/feb31b6e-6457-454c-a4f3-ce8ad96bf8de@amd.com/