Re: [RESEND][PATCH v31 1/9] sched/deadline: Ignore proxy-exec sched_yield()

[John Stultz]

On Mon, Aug 10, 2026 at 8:57 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Fri, Aug 07, 2026 at 03:52:07AM +0000, John Stultz wrote:
> > From: Christian Loehle <christian.loehle@xxxxxxx>
> >
> > With proxy execution, rq->curr is the execution context while rq->donor is
> > the donating context. rq->curr's sched_yield() is dispatched through
> > the donor class so that proxy execution follows the effective scheduling
> > context.
> >
> > For SCHED_DEADLINE, this is too strong. yield_task_dl() does not just ask
> > for another task of equal priority to get to run, it marks the current DL
> > entity as yielded and forces it to sleep until replenishment. These
> > yield semantics are fundamentally different from FIFO/RR (where if no
> > equal-priority tasks are runnable, no harm done, they get picked again
> > immediately) or OTHER (also doesn't cause priority inversion), so do not
> > mix these semantics by ignoring a sched_yield() on DL donors.
> >
> > Fixes: 127b90315ca0 ("sched/proxy: Yield the donor task")
> > Acked-by: Juri Lelli <juri.lelli@xxxxxxxxxx>
> > Signed-off-by: Christian Loehle <christian.loehle@xxxxxxx>
> > Signed-off-by: John Stultz <jstultz@xxxxxxxxxx>
>
> > ---
> >  kernel/sched/deadline.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 0f858b98c9aa3..3e89b3abeb278 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -2574,6 +2574,9 @@ static bool dequeue_task_dl(struct rq *rq, struct task_struct *p, int flags)
> >   */
> >  static void yield_task_dl(struct rq *rq)
> >  {
> > +     if (sched_proxy_exec() && rq->curr != rq->donor)
> > +             return;
> > +
> >       /*
> >        * We make the task go to sleep until its current deadline by
> >        * forcing its runtime to zero. This way, update_curr_dl() stops
>
> I am not sure...
>
> Yes, we should not yield the donor. However, completely ignoring the
> yield() is also wrong.
>
> Now, the only way to actually hit this is by doing yield() while being a
> lock owner. And arguably that is quite insane. But still, completely
> ignoring it sounds wrong too.

Ok. I'll drop this out of my current submission series.

>
> Can't we 'queue' the yield and have it be effective the moment the donor
> goes away?

I'll have to look more into it. It almost seems like we might be able
to set dl_yielded on the rq->curr and then return in the proxy case,
but I need to read through the paths more and would defer to Juri or
Christian.

thanks
-john