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

[Juri Lelli]

On 11/08/26 09:25, K Prateek Nayak wrote:
> Hello John, Peter,
> 
> On 8/11/2026 12:55 AM, John Stultz wrote:
> > 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?
> 
> Question: What does rt_mutex do in this case?
> 
> From my limited understanding, for rt_mutex, we hit the is_dl_boosted(dl_se)
> condition in the throttle label in update_curr_dl_se() and then we do a:
> 
>     enqueue_task_dl(rq, dl_task_of(dl_se), ENQUEUE_REPLENISH);
> 
> Would same work for proxy too where we can essentially consider
> "dl_task(donor) && rq->donor != rq->curr" as is_dl_boosted() and continue
> with the "boost overrides the throttle" rule?

I believe we want to remove the existing hack once we have proxy
execution in place. At that point we should be able to enfore bandwidth
properly across inheritance chains.

yield() while holding a lock is indeed insane in theory, but in practice
one might not be in full control of what other software layers are
doing. So, maybe what Peter is proposing could be a viable practical
middle ground. Wonder if should anyway at least WARN about it.