Re: [PATCH 07/15] sched_ext: Block proxy donors across scheduler transitions

[Andrea Righi <arighi@nvidia.com>]

Hi Tejun,

On Mon, Aug 03, 2026 at 10:36:40AM -1000, Tejun Heo wrote:
> On Tue, Jul 28, 2026 at 05:43:25PM +0200, Andrea Righi wrote:
> ...
> > +static void prepare_switch_scx(struct rq *rq, struct task_struct *p)
> > +{
> > +	lockdep_assert_held(&p->pi_lock);
> > +	lockdep_assert_rq_held(rq);
> > +
> > +	sched_proxy_block_task(rq, p);
> >  }
> 
> Are there use cases where proxy execution instance needs to survive across
> class changes (the mutex rt PI, maybe)? If not, maybe this can be the global
> behavior?

I think RT/DL PI is a use case where a proxy donor needs to survive a class
change. Example:

  H (RT) waits on rtmutex R owned by D
  D (FAIR) waits on normal mutex M owned by O

rt_mutex_setprio(D, H) promotes D from FAIR to RT. If D remains a retained proxy
donor, its new RT scheduling context can proxy-exec O, allowing O to release M,
then D to release R.

If every class transition called sched_proxy_block_task(), D would be removed
from the runqueue when FAIR->RT occurs. The PI boost would then stop at the
ordinary mutex boundary, and O would execute only under its own scheduling
context. The same issue exists for RT/DL deboost transitions.

Potentially this could be generalized in core as a per-class "supports retained
proxy donors" capability, but unconditional global blocking would discard useful
PI behavior.

Thanks,
-Andrea