Re: [PATCH 04/12] sched_ext: Avoid migrating blocked tasks with proxy execution

[Andrea Righi <arighi@nvidia.com>]

Hi Maria,

On Fri, Jul 03, 2026 at 04:02:16PM +0800, Aiqun(Maria) Yu wrote:
> On 7/3/2026 1:09 AM, Andrea Righi wrote:
> > From: John Stultz <jstultz@google.com>
> > 
> > With proxy execution enabled, mutex blocked tasks stay on the runqueue.
> > Later with donor migration they will be migrated when necessary by the
> > core scheduler to boost lock owners.
> > 
> > Don't try to migrate mutex blocked tasks, the proxy logic will handle
> > that.
> > 
> > Co-developed-by: Andrea Righi <arighi@nvidia.com>
> > Signed-off-by: Andrea Righi <arighi@nvidia.com>
> > Signed-off-by: John Stultz <jstultz@google.com>
> 
> SOB was suggested to have the current committer at the last line.
> Not sure if it is the same rule for the subsystem here.
> 
> My understanding would be:
> Signed-off-by: John Stultz <jstultz@google.com>
> Co-developed-by: Andrea Righi <arighi@nvidia.com>
> Signed-off-by: Andrea Righi <arighi@nvidia.com>

You're right, I'll fix it in the next version.

> 
> 
> > ---
> >  kernel/sched/ext/ext.c | 25 +++++++++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> > index 1588565050679..9a672b9a55f6e 100644
> > --- a/kernel/sched/ext/ext.c
> > +++ b/kernel/sched/ext/ext.c
> > @@ -2150,6 +2150,14 @@ static bool task_can_run_on_remote_rq(struct scx_sched *sch,
> >  
> >  	WARN_ON_ONCE(task_cpu(p) == cpu);
> >  
> > +	/* Make sure tasks aren't on a cpu */
> > +	if (task_on_cpu(task_rq(p), p))
> > +		return false;
> > +
> > +	/* Don't migrate blocked tasks, proxy-exec will handle this */
> > +	if (task_is_blocked(p))
> > +		return false;
> 
> what about return true here for owner_cpu?
> if the owner_cpu is in the move_task_between_dsqs stage for example.

Good point. Returning false for every blocked task is too restrictive, because
it'd reject potential remote placements requested by the BPF scheduler from
ops.enqueue().

But we can't simply return true either, otherwise we would bypass all the checks
below, allowing sched_ext to move the donor even if the destination is outside
its affinity mask or the destination rq is offline.

I think we should do something like this:

  if (task_is_blocked(p) && task_current_donor(task_rq(p), p))
          return false;

In practice, normal migration can happen if a blocker donor is not already the
rq's current scheduling context.

With that, the BPF scheduler should be able to decide the "call back home" CPU
for the donor, if it performs a direct dispatch to a local DSQ different than
its current CPU's local DSQ.

Thanks,
-Andrea