On 09/01/2026 14:48, Philipp Stanner wrote:
On Fri, 2026-01-09 at 14:06 +0000, Tvrtko Ursulin wrote:
8><
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.
Yes and no. Yes, the CFS series makes sched:rq 1:1. No, the other series
is not overlapping but is adding on top of CFS.
It establishes runtime invariant sched:entity relationship for 1:1
users. And by making run-queue operation vfuncs dependant on M:N vs 1:1
scheduler usage, the latter removes the need for 1:1 to manage the
rbtree, the entity list, and probably some other simplifications which I
forget from the top of my head. It kind of tries to start working in the
direction of splitting the frontend and "backend" of the scheduler
better for those two different use cases.
Regards,
Tvrtko
