On 14/09/2026 10:37, Philipp Stanner wrote:
+Cc Michel (for the sched policy removal plan)
On Mon, 2026-09-14 at 09:59 +0100, Tvrtko Ursulin wrote:
On 11/09/2026 10:36, Philipp Stanner wrote:
Someone from RH might or might not work on that, and perhaps that would
take until 2027. I'm keeping an eye open for people to pick it up, but
everyone's always busy.
Again, I am happy to work on that as long as it is clear there is no
duplication of effort.
I asked and made sure no one is working on it, so from our POV you have
green light.
Regarding the bugfix, this was reported as a performance issue on high
load, that only seems to be reachable for CFS users, a brand-new policy
that is marked as experimental and is not used by anyone in production
yet. So IMO we can move on on drm-misc-next with spsc-queue, which will
also make CFS usable then.
I think more logical order is to first fix it with a small backportable
fix even if experimental. That way people using 7.2 can actually test it
and contribute valuable feedback.
I took another look and I think my only issue is basically just that
the patch addresses something which we should have done regardless of
the bug at hands. So I'd be already happy if the commit just had a
different title and slightly extended commit message, like:
"drm/sched: Fix vruntime race by extending locking"
plus sth like
"this simultaneously serves as a preparational step to replace the
spsc_queue as a whole".
As I think it is fine as is I would prefer not to spend time on a respin
unless you insist.
Is there a plan btw as to how you would like to proceed with CFS?
So for me the most typical and useful plan, and in the context of the
desired spsc removal, is:
- Merge this fix so it gets into 7.2
- Spsc removal RFC for some upcoming release N.
- Remove experimental status from fair policy for kernel release >= N.
- Switch fair to default at >= N+1.
Couldn't it be enabled first for dedicated users? AFAIK it was
developed with Steam's gaming platforms in mind. Can their OS devs be
asked to switch it on or test it downstream?
It wasn't quite developed for single game use cases, but with the wider
goal of improving the code base and DRM landscape in general.
Also, I think it could give us false confidence since the matrix of
hardware + kernel setups is quite small. Even this bug wasn't caught on
an official platform, neither could I repro it on a Steam Deck. So I
would say a release or two after it is set as default is quite safe
since it can be easily reverted with a one line change.
Regards,
Tvrtko
- Remove FIFO and RR and simplify to single embedded run queue at >= N+2.
