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

[Andrea Righi <arighi@nvidia.com>]

On Thu, Sep 10, 2026 at 12:38:18PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 31, 2026 at 03:42:17PM +0200, Andrea Righi wrote:
> > Proxy execution splits the scheduling context (the donor) from the
> > execution context (the lock owner). sched_ext needs to observe that
> > split at three points in __schedule():
> > 
> >  - whether a blocked EXT task can be retained on the runqueue as a
> >    donor,
> >  - when a donor's scheduling context starts driving a lock owner,
> >  - once proxy resolution has settled for the current pick.
> > 
> > Introduce scx_allow_proxy_exec(), scx_proxy_donor_start() and
> > scx_proxy_resolved(), and add their call sites in __schedule(). The
> > implementations are empty here and are filled in by the sched_ext
> > changes that follow, so that all the sched core changes needed by proxy
> > execution stay together in the preparatory patches.
> > 
> > SCHED_PROXY_EXEC still depends on !SCHED_CLASS_EXT, so the new hooks are
> > inert: they are compiled out with CONFIG_SCHED_CLASS_EXT=n and
> > unreachable otherwise.
> > 
> > This is a preparatory change to support proxy execution with sched_ext.
> > No functional change.
> > 
> > Signed-off-by: Andrea Righi <arighi@nvidia.com>
> > ---
> >  kernel/sched/core.c    | 12 +++++++-----
> >  kernel/sched/ext/ext.c | 13 +++++++++++++
> >  kernel/sched/ext/ext.h |  6 ++++++
> >  3 files changed, 26 insertions(+), 5 deletions(-)
> > 
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index bb79fcfa21cd2..d578dd635f2eb 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -7217,13 +7217,12 @@ static void __sched notrace __schedule(int sched_mode)
> >  		}
> >  	} else if (!preempt && prev_state) {
> >  		/*
> > -		 * We pass task_is_blocked() as the should_block arg
> > -		 * in order to keep mutex-blocked tasks on the runqueue
> > -		 * for slection with proxy-exec (without proxy-exec
> > -		 * task_is_blocked() will always be false).
> > +		 * Keep mutex-blocked tasks on the runqueue for proxy execution
> > +		 * only when their scheduling class allows it. Without proxy
> > +		 * execution, task_is_blocked() always returns false.
> >  		 */
> >  		try_to_block_task(rq, prev, &prev_state,
> > -				  !task_is_blocked(prev));
> > +				  !task_is_blocked(prev) || !scx_allow_proxy_exec(prev));
> >  		switch_count = &prev->nvcsw;
> >  	}
> >  
> > @@ -7244,6 +7243,7 @@ static void __sched notrace __schedule(int sched_mode)
> >  			}
> >  			if (next == rq->idle) {
> >  				zap_balance_callbacks(rq);
> > +				scx_proxy_resolved(rq);
> >  				goto keep_resched;
> >  			}
> >  		}
> > @@ -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?

Thanks,
-Andrea