Re: [PATCH] sched/proxy_exec: Handle sched_delayed owner in find_proxy_task()

[John Stultz]

On Mon, Mar 2, 2026 at 10:43 PM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 3/3/2026 12:00 PM, soolaugust@xxxxxxxxx wrote:
> > Right. I'll send a v2 that keeps the two checks as separate blocks
> > (the conceptual distinction is worth preserving for when the blocked-
> > owner series lands), but uses proxy_deactivate() for both:
> >
> >     if (!READ_ONCE(owner->on_rq)) {
> >         return proxy_deactivate(rq, donor);
> >     }
> >     if (owner->se.sched_delayed) {
> >         /*
> >          * Owner is in EEVDF deferred-dequeue: still physically on
> >          * the runqueue but has called schedule(). A sched_delayed
> >          * task never has blocked_on set, so the chain cannot be
> >          * followed further. Deactivate the donor for now; proper
> >          * handling will come with the blocked-owner series.
> >          *
> >          * XXX: Don't handle sched_delayed owners yet.
> >          */
> >         return proxy_deactivate(rq, donor);
> >     }
> >
> > The comment replaces the shared "XXX" with per-case rationale, making
> > it clearer why they are handled differently once proper support lands.
> >
> > Does that work, or would you prefer the two conditions be collapsed
> > back into one?
>
> I suppose we can expand on that comment but all of this will go away
> soon(ish) anyways. Do we need to modify it?
>
> I'll let John, Peter answer what they think is best. Personally, I
> feel the current transient comment is good enough indicating that it'll
> be handled with the upcoming changes similar to owner on remote CPU.

Again, thank you to K Prateek for his excellent analysis and response
in this thread.

Admittedly, being half way through upstreaming the proxy-exec series,
the code is a little awkward. But even in my current full patch
series, I handle (!on_rq || sched_delayed) together as the logic ends
up being the same. So I'm not sure splitting the two conditions out is
really valuable.

Even though sched_delayed is in some sense transient, for proxy-exec
it's not meaningfully different than !on_rq, its just an intermediate
step.  Either the task is woken up (same as with a !on_rq task) or the
dequeue completes (and it becomes !on_rq).

If there are proposals for ways to handle sched_delayed differently to
some benefit, then I'm open to splitting it out, but I'm not sure I
see it yet.

thanks
-john