Re: [PATCH 07/18] sched: Add sched_ext hooks for proxy execution

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Sep 15, 2026 at 10:30:38PM +0200, Andrea Righi wrote:
> On Thu, Sep 10, 2026 at 12:38:18PM +0200, Peter Zijlstra wrote:

> > > @@ -7264,6 +7264,8 @@ static void __sched notrace __schedule(int sched_mode)
> > >  			donor->sched_class->put_prev_task(rq, donor, donor);
> > >  			donor->sched_class->set_next_task(rq, donor, true);
> > >  		}
> > > +		scx_proxy_donor_start(rq);
> > > +		scx_proxy_resolved(rq);
> > >  	} else {
> > >  		rq_set_donor(rq, next);
> > >  	}
> > 
> > Can you expand on the need for scx_proxy_resolved() ? I understand the
> > other two, but this one I'm struggling with a bit.
> 
> Yeah and the name is a poor choice, it should renamed
> scx_proxy_reenqueue_retry() or something similar.
> 
> It's the retry point for a task that sched_ext couldn't move while
> processing a dispatch from a remote DSQ (used later in the series).
> 
> When sched_ext consumes a task dispatched to a CPU other than the one
> whose rq currently owns it, it may find (after locking the task's
> source rq) that proxy exec has made the task either the physical
> current task or the active donor. It can't migrate the task in that
> state, so it parks the task on the source rq's reject DSQ.
> 
> If the deferred reject-DSQ drain runs while the task is still current
> or donating, the task must remain parked. Retrying immediately could
> spin until the proxy relationship changes. The hook provides the
> notification that proxy selection has run again, allowing sched_ext to
> schedule another deferred drain after the current context switch.
> 
> I couldn't find an existing event that covers this transition without
> periodically retrying the reject-DSQ drain. Is there a better place to
> trigger this retry?

Ah, so its a little like that problem we had with ->balance() and
->pick_task(). Where a task gets taken off the DSQ and moved to the
local queue, but when not picked, it must be moved back.

In this case, ->donor is visible to ext and all is well, but ->curr is
not so easy.

I'm still a little confused though, why not leave blocked tasks on this
reject queue. If they're needed, the proxy mechanism will move them
around. They won't actually ever run except through proxy.

The point where they will become runnable again, is through wakeup. So
why not delay everything until that point?

Or am I not understanding ext again?