On 11/09/2026 10:36, Philipp Stanner wrote:
On Fri, 2026-09-11 at 10:18 +0100, Tvrtko Ursulin wrote:
So basically you move for locking the spsc-queue, the lockless queue
which is usually used with the locks next to it anyways. That's cool
stuff. I've suggested this for a while already
https://docs.kernel.org/gpu/todo.html#replace-the-lockless-queue-with-a-locked-list
So from a maintainability perspective, it would be far cooler if you go
down this road one step further and kill the spsc_queue for good,
replacing it with a fully locked list. AFAIR Christian and Danilo also
have agreed to this.
I am happy to work on that just that a) I thought some time back you
said someone from RedHat will tackle it, and b) lets please not gate
this bugfix on that.
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.
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.
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.
- Remove FIFO and RR and simplify to single embedded run queue at >= N+2.
Regards,
Tvrtko
