EEVDF regression still exists
Prundeanu, Cristian
cpru at amazon.com
Fri May 2 09:52:38 PDT 2025
On 2025-05-02, 03:50, "Peter Zijlstra" <peterz at infradead.org <mailto:peterz at infradead.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.
More information about the linux-arm-kernel
mailing list