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: <f241b773-fca8-4be2-8a84-5d3a6903d837@amd.com>
Date: Wed, 30 Apr 2025 09:03:26 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: "Prundeanu, Cristian" <cpru@...zon.com>, Peter Zijlstra
	<peterz@...radead.org>
CC: "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

Hello Cristian,

On 4/30/2025 3:36 AM, Prundeanu, Cristian wrote:
> 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).

So I never tried comparing SCHED_BATCH on both old vs new kernel for
the HammerDB benchmark since SCHED_BATCH had not led to a great
improvement in the baseline numbers on v6.5 in my previous debugs and
I was mostly looking at context-switch data, trying to match the EEVDF
case to baseline numbers.

I'll try to setup the reproducer you have posted on my end and reach
out if I run into any issues. Hopefully the exact setup reveals
something I've overlooked.

P.S. Are the numbers for v6.15-rc4 + SCHED_BATCH comparable to v6.5
default?

One more curious question: Does changing the base slice to a larger
value (say 6ms) in conjunction with setting SCHED_BATCH on v6.15-rc4
affect the benchmark result in any way?

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

-- 
Thanks and Regards,
Prateek