Re: [PATCH v2] [tip: sched/core] sched: Move PLACE_LAG and RUN_TO_PARITY to sysctl
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [PATCH v2] [tip: sched/core] sched: Move PLACE_LAG and RUN_TO_PARITY to sysctl
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Date: Wed, 12 Feb 2025 10:17:11 +0100
- Cc: K Prateek Nayak <kprateek.nayak@xxxxxxx>, Hazem Mohamed Abuelfotoh <abuehaze@xxxxxxxxxx>, Ali Saidi <alisaidi@xxxxxxxxxx>, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>, Geoff Blake <blakgeof@xxxxxxxxxx>, Csaba Csoma <csabac@xxxxxxxxxx>, Bjoern Doebel <doebel@xxxxxxxxxx>, Gautham Shenoy <gautham.shenoy@xxxxxxx>, Joseph Salisbury <joseph.salisbury@xxxxxxxxxx>, Dietmar Eggemann <dietmar.eggemann@xxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-tip-commits@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx
- In-reply-to: <20250212053644.14787-1-cpru@amazon.com>
- References: <20250119110410.GAZ4zcKkx5sCjD5XvH@fat_crate.local> <20250212053644.14787-1-cpru@amazon.com>
On Tue, Feb 11, 2025 at 11:36:44PM -0600, Cristian Prundeanu wrote:
> Replacing CFS with the EEVDF scheduler in kernel 6.6 introduced
> significant performance degradation in multiple database-oriented
> workloads. This degradation manifests in all kernel versions using EEVDF,
> across multiple Linux distributions, hardware architectures (x86_64,
> aarm64, amd64), and CPU generations.
>
> Testing combinations of available scheduler features showed that the
> largest improvement (short of disabling all EEVDF features) came from
> disabling both PLACE_LAG and RUN_TO_PARITY.
>
> Moving PLACE_LAG and RUN_TO_PARITY to sysctl will allow users to override
> their default values and persist them with established mechanisms.
Nope -- you have knobs in debugfs, and that's where they'll stay. Esp.
PLACE_LAG is super dodgy and should not get elevated to anything
remotely official.
Also, FYI, by keeping these emails threaded in the old thread I nearly
missed them again. I'm not sure where this nonsense of keeping
everything in one thread came from, but it is bloody stupid.
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]