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

[Andrea Righi <arighi@nvidia.com>]

On Mon, Jul 20, 2026 at 05:37:29PM -0700, John Stultz wrote:
> On Mon, Jul 20, 2026 at 9:02 AM Andrea Righi <arighi@nvidia.com> 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?

Sounds like a good plan! It'd be helpful if you could include
"sched: Distinguish proxy activations from wakeups" at the end of your
sleeping-owner series.

I'll move the combined version to scx-proxy-exec-sleeping-owner for testing and
rebase the scx-proxy-exec series without the sleeping-owner changes, so that it
can move forward independently for now.

Thanks!
-Andrea