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

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 16, 2026 at 05:52:42PM +0200, Andrea Righi wrote:

> > 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?
> 
> I think the missing detail is that the task rejected by the remote DSQ transfer
> isn't necessarily blocked.
> 
> Consider a blocked donor D proxy-executing a runnable EXT mutex owner
> O on CPU0.  O is rq->curr and D is rq->donor. Since O is executing
> using D's scheduling context, O's own EXT scheduling entity may still
> be on a non-local DSQ.
> 
> CPU1 could concurrently consume O from that non-local DSQ and start
> transferring it to CPU1. After dropping the DSQ lock and acquiring O's
> source rq lock, it discovers that O has become rq->curr on CPU0 and
> therefore can't be migrated.  O is then parked on CPU0's reject DSQ.
> 
> When proxy exec switches away from O, O stops being rq->curr but
> remains runnable. There's no wakeup in this case, because O never
> blocked. If it remains on the reject DSQ, it's no longer visible to
> the BPF scheduler and can't subsequently run using its own scheduling
> context.

Argh, right! I got D and O switched around :-/

> The rq->donor case has a similar issue even though that task is
> blocked: a blocked donor can stop being the active donor before the
> mutex wakes it (for example, if another scheduling context is
> selected). The proxy exec mechanism follows the owner chain after the
> donor has been selected, it doesn't select tasks from the internal
> reject DSQ. Leaving the donor there until wakeup would prevent it from
> being selected again for proxy execution in the meantime.

Ah, but rq->donor gets a put_prev_task() to sort it out. While there is
no such things for rq->curr.

> This is why the retry is tied to another proxy selection point, once
> the task is no longer rq->curr or rq->donor, it can be re-enqueued to
> through its BPF scheduler.

Fair enough.