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: <935376C2-71B9-4E41-9738-99A4BCC55B48@amazon.com>
Date: Fri, 2 May 2025 16:52:38 +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>,
	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-05-02, 03:50, "Peter Zijlstra" <peterz@...radead.org <mailto:peterz@...radead.org>> wrote:

> On Thu, May 01, 2025 at 04:16:07PM +0000, Prundeanu, Cristian wrote:
> 
>> (Please keep in mind that the target isn't to get SCHED_BATCH to the same
>> level as 6.5-default; it's to resolve the regression from 6.5-default to
>> 6.6+ default, and from 6.5-SCHED_BATCH to 6.6+ SCHED_BATCH).
>
> No, the target definitely is not to make 6.6+ default match 6.5 default.
>
> The target very much is getting you performance similar to the 6.5
> default that you were happy with with knobs we can live with.

If we're talking about new knobs in 6.6+, absolutely.

For this particular case, SCHED_BATCH existed before 6.6. Users who already
enable SCHED_BATCH now have no recourse. We can't, with a straight face,
claim that this is a sufficient fix, or that there is no regression.

I am, of course, interested to discuss any knob tweaks as a stop-gap measure.
(That is also why I proposed moving NO_PLACE_LAG and NO_RUN_TO_PARITY to sysctl
a few months back: to give users, including distro maintainers, a reasonable
way to preconfigure their systems in a standard, persistent way, while this is
being worked on).
None of this should be considered a permanent solution though. It's not a fix,
and was never meant to be anything but a short-term relief while debugging the
regression is ongoing.