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?). 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.
