Re: [PATCH 08/11] sched_ext: Delegate proxy donor admission to BPF schedulers

[John Stultz]

On Mon, Jul 20, 2026 at 9:02 AM Andrea Righi <arighi@xxxxxxxxxx> wrote:
> On Sat, Jul 18, 2026 at 04:23:40PM +0200, Andrea Righi wrote:
> > On Fri, Jul 17, 2026 at 11:50:20PM -0700, John Stultz wrote:
> > > I'll work to prove this out a bit further next week.  I suspect we'll
> > > need something somewhere between activate_blocked_waiters() ->
> > > scx_do_enqueue_task() to skip enquing of is_blocked tasks when
> > > SCX_OPS_ENQ_BLOCKED isn't set.
> >
> > Your theory looks correct to me. I was also able to reproduce this. I think the
> > problem is that scx_prepare_task_sched_change() calls sched_proxy_block_task(),
> > but the latter has nothing to do when the donor is already off the runqueue
> > behind a sleeping owner.
> >
> > When the owner subsequently wakes, activate_blocked_waiters() unconditionally
> > reactivates the donor while is_blocked is still set. Since this activation
> > carries ENQUEUE_WAKEUP, sched_ext treats it as a normal wakeup rather than a
> > blocked-donor admission. The donor can therefore enter an scx scheduler that
> > doesn't set SCX_OPS_ENQ_BLOCKED (scx_pair in this case), eventually triggering
> > the warning in put_prev_task_scx(): unexpected proxy donor without
> > SCX_OPS_ENQ_BLOCKED set.
> >
> > I think we can fix this by checking scx_allow_proxy_exec() in
> > do_activate_blocked_waiter() before reactivating the donor. If the scx scheduler
> > doesn't support proxy donors (SCX_OPS_ENQ_BLOCKED not set), the task should
> > remain blocked and will be activated normally by the mutex wakeup.
> >
> > While looking at this, I noticed another issue in the same path:
> > activate_blocked_waiters() currently passes ENQUEUE_WAKEUP because the generic
> > scheduling classes need wakeup-style enqueue accounting. However, this is not a
> > real mutex wakeup, the donor remains blocked and is only being made runnable so
> > that it can donate its scheduling context.
> >
> > As a result, even a scheduler that sets SCX_OPS_ENQ_BLOCKED currently receives
> > this sleeping-owner activation as SCX_ENQ_WAKEUP rather than SCX_ENQ_BLOCKED.
> > That's because the existing sched_ext test:
> >
> >   p->is_blocked && !(enq_flags & SCX_ENQ_WAKEUP)
> >
> > doesn't distinguish a genuine mutex wakeup from this proxy activation.
> >
> > Maybe we can address this by adding an internal ENQUEUE_PROXY flag to the
> > sleeping-owner activation. The generic classes will continue to see
> > ENQUEUE_WAKEUP, preserving their accounting behavior, while sched_ext will use
> > ENQUEUE_PROXY to expose the event to BPF as SCX_ENQ_BLOCKED without
> > SCX_ENQ_WAKEUP. And a genuine mutex wakeup will continue to be reported as
> > SCX_ENQ_WAKEUP. What do you think?
>
> FYI, I've applied your sleeping owner changes + the scx-proxy-exec patch series
> with the changes mentioned above here:
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/arighi/linux.git scx-proxy-exec-next
>
> Everything looks good on my side so far.

That's awesome! Thank you for your efforts here!  I'll start testing
and playing around with this branch!

Though, looking at your patch stack, I'd rather not make my patches
under review a dependency for your patches.  Peter has not yet put his
laser-eyes upon my series so there's no telling how much rework they
may need (and it does have some subtle parts that I'm sure he'll have
feedback on). So just to allow your current series to be able to move
foward, would it make sense if I added your "sched: Distinguish proxy
activations from wakeups" patch to the end of my series?  It looks
like there's not much interlock on the rest of your changes (though
I've not carefully reviewed the diff from your scx-proxy-exec branch
as they are on different bases), so maybe that would just work and the
rest of your series could move forward?

thanks
-john