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

[Andrea Righi <arighi@nvidia.com>]

On Wed, Aug 05, 2026 at 09:02:10AM +0200, Andrea Righi wrote:
> 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.

Following up on my response to patch 12 (which essentially contradicts my
earlier response here), we can probably take a more conservative approach for
now and leave more selective handling for future work.

While preserving a proxy session across some RT/DL PI class transitions is
useful, terminating retained proxy execution centrally in sched_change_begin(),
whenever the scheduling class changes, simplifies the implementation and it can
make the initial integration safer.

In the next version of this series I'll document this limitation in both the
code and patch description and leave support for compatible RT/DL PI transitions
as a future improvement.

Thanks,
-Andrea