Re: [PATCHSET v14 sched_ext/for-7.4] sched: Make proxy execution compatible with sched_ext

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Sep 25, 2026 at 09:46:40AM +0200, Andrea Righi wrote:
> Hi Peter,
> 
> On Thu, Sep 24, 2026 at 09:52:37AM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 22, 2026 at 06:51:39PM +0200, Andrea Righi wrote:
> > 
> > > Andrea Righi (16):
> > >       sched/core: Drop mutex locks before proxy rescheduling
> > >       sched/core: Dequeue waking proxy donors before reset
> > >       sched/core: Mark wakeups completed through ttwu_runnable()
> > >       sched: Add helper to block retained proxy donors
> > >       sched: Add sched_ext hooks for proxy execution
> > 
> > Right, so these add:
> > 
> > WF_TTWU_RQ:
> > 
> >   Used like ENQUEUE_DELAYED; could be fixed by generalizing that to cover all
> >   of p->is_blocked.
> > 
> > scx_allow_proxy_exec():
> > 
> >   Hook to kill proxy exec for scx
> > 
> > scx_proxy_reenqueue_retry():
> > 
> >   Like put_prev_task(), but for current. Ensures current gets put back on a DSQ
> >   once its done running.
> > 
> > scx_proxy_donor_start():
> > 
> >   Delayed set_next_task(), confirms donor will be used.
> > 
> > sched_proxy_block_task():
> > 
> >   Almost like switching_to_scx(), except it needs to change ctx->queued in case
> >   of p->is_blocked. Hence a new callback ran before sched_change_begin().
> 
> Yes, that matches the intent, with one small clarification:
> scx_proxy_reenqueue_retry() doesn't directly put current back on a DSQ, a task
> that couldn't be reenqueued remains on the reject DSQ and the hook schedules a
> deferred retry after proxy resolution.
> 
> > 
> > 
> > 
> > Now, I have:
> > 
> >   https://patch.msgid.link/20260917-sched-fair-hrtick-restart-v4-1-4dd1414da81a@gentwo.org,
> > 
> > pending, would something like the below on top of both this work?
> > 
> > (although I'm not convinced SC_CONFIRM is actually making it better)
> 
> Yes, this works.
> 
> I applied Shubhang's v4 hrtick patch as a preliminary commit, then added the
> SNT_CONFIRM callback and reworked the proxy-exec series to use it. sched_ext now
> confirms the donor in set_next_task_scx() and scx_proxy_donor_start() is gone.
> 
> I tested the updated series and it passed all my scx proxy exec tests. The
> branch is available here:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/arighi/linux.git scx-proxy-exec-next
> 
> It's not an obvious simplification, but if we want to go this way, we can
> express both the provisional pick and donor confirmation through the sched class
> callback.

Yeah, I'm not convinced either, but I'm also not liking scx specific
hooks. I'll apply your patches as is, and we can noodle on the
difference later.

TJ, would you like me to take the sched_ext part of this series too, or
will you pull in sched/core after these land and then put those patches
on top in your tree?