Re: [PATCH 09/12] sched_ext: Delegate proxy donor admission to BPF schedulers

[Andrea Righi <arighi@nvidia.com>]

Hi Prateek,

On Fri, Jul 03, 2026 at 12:11:40AM +0530, K Prateek Nayak wrote:
> Hello Andrea,
> 
> On 7/2/2026 10:39 PM, Andrea Righi wrote:
> > @@ -7148,7 +7181,8 @@ static void __sched notrace __schedule(int sched_mode)
> >  		 * task_is_blocked() will always be 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;
> >  	}
> >  
> > diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> > index c48d043dbe58f..8ffbf857acd51 100644
> > --- a/kernel/sched/ext/ext.c
> > +++ b/kernel/sched/ext/ext.c
> > @@ -23,6 +23,14 @@
> >  
> >  DEFINE_RAW_SPINLOCK(scx_sched_lock);
> >  
> > +bool scx_allow_proxy_exec(const struct task_struct *p)
> > +{
> > +	if (!task_on_scx(p))
> > +		return true;
> > +
> > +	return scx_task_sched(p)->ops.flags & SCX_OPS_ENQ_BLOCKED;
> > +}
> > +
> 
> What happens when we switch in a a sched-ext scheduler that
> doesn't support proxy?
> 
> There would be a bunch proxy donors already preset at the time of the
> scheduler loading but I don't see anything in the enable path that
> would take care of those tasks by blocking them completely.
> 
> Is it handled elsewhere?

Good catch! It's not currently handled, a proxy donor that blocked before
sched_ext was enabled can remain queued after being transferred to a scheduler
that doesn't have SCX_OPS_ENQ_BLOCKED.

We should probably deactivate existing blocked donors while switching them to a
scheduler without proxy support.

I'll fix this in the next version and add this case to the kselftest.

Thanks,
-Andrea