Re: [PATCH 12/17] sched_ext: Handle proxy-exec races in remote DSQ transfers

On Mon, Aug 17, 2026 at 09:32:38PM +0200, Andrea Righi wrote:
> > But wouldn't it be able to use the same schedule_deferred_locked() call like
> > SCX_DSQ_REJECT case so that the PROXY_REENQ flag is only used for retry
> > cases (and maybe renamed accordingly)?
> 
> Yes. The initial insertion into reject_dsq can use schedule_deferred_locked()
> without setting a proxy-specific flag. Then we can set the flag only when
> scx_reenq_reject() actually skips a task because it is still running or
> donating. How about renaming to SCX_RQ_PROXY_RETRY to refelct the new meaning?

Sounds good to me.

> > I think this is a generic problem with core scheduling. SCX assumes that
> > deferred scheduilng always runs but core-sched can zap them. We probably
> > need to address this directly using a similar but generic deferred work
> > pending flag.
> 
> Agreed. This isn't specific to proxy-rejected tasks, any sched_ext deferred work
> queued through a balance callback can be lost if core scheduling zaps the
> callback.
> 
> Maybe we can introduce a new generic sched_ext deferred work pending flag, kept
> set until the deferred work actually runs and we can use it to rearm it after
> callback cancellation?
> 
> Probably something to do for another patch series...

Yeap.

Thanks.

-- 
tejun