On 1/9/26 15:48, Philipp Stanner wrote: > On Fri, 2026-01-09 at 14:06 +0000, Tvrtko Ursulin wrote: >> \ >> On 07/01/2026 14:11, Philipp Stanner wrote: >>> Happy 2026, Tvrtko! >>> >>> > > […] > >>> Not to long ago we discussed that the spsc_queue should be removed and >>> replaced by some sort of list, with proper locks. Christian has agreed >>> that this should fly. >>> >>> The spsc queue has only 1 user in the kernel and it's super hard to >>> understand how it's supposed to work and when any why barriers and >>> READ_ONCE's are necessary (that's, of course, also not documented in >>> the queue). >>> >>> Until that is done I don't really want to touch any of those memory >>> barriers.. >> >> (I had a branch with spsc gone more than a year ago but I abandoned it >> for now since it contained some other too ambitious changes. So no >> complaints from me. Who is doing it BTW?) > > No one is working on it. > > But I think the discussion has succeeded. The only objector was > Christian because he was worried about some cache-line performance > regression. I can't remember for sure, but I think Christian realized > that cache lines are not an issue (with a hlist?).
Well I'm ok with it as long as you don't regress some specific performance test cases. The problem is that those performance test cases are ancient, e.g. glmark2 on modern HW for example. So you don't exercise the HW in any way, but rather how fast submissions can be pushed to the HW. And yeah I'm perfectly aware that such tests are completely nonsense. Regards, Christian. > If you want to pick up removing SPSC-queue, be my guest, but make sure > to discuss it with Christian before investing too much of your time. > >> >> Back to the point - this patch can wait, no problem. To explain the >> context though. >> >> I wanted to get rid of looking at the list_empty here because I have a >> branch which improves the flow for the 1:1 sched:entity drivers. >> >> Why are the two related? If you remember in the fair scheduler series >> all the run-queue stuff is nicely grouped in sched_rq.c and encapsulated >> in the rq API, which made it possible to follow up with virtualizing the >> rq operations. >> >> The yet another relevant thing is the patch I sent this week which >> removes the special case where entity can be initialized with no schedulers. >> >> If we combined all these three pre-requisites, my branch allows the >> fully invariant sched:entity and 1:1:1 sched:rq:entity. Run-queue vfuncs > > Hm, wouldn't the CFS series annihilate multiple RQs anyways? This > sounds as if there are several series' floating around, cleaning up > similar things. > > > P.
