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

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Zhidao,

On 3/3/2026 12:00 PM, soolaugust@gmail.com 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.

-- 
Thanks and Regards,
Prateek