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

[K Prateek Nayak <kprateek.nayak@amd.com>]

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@infradead.org> wrote:
>> On Fri, Aug 07, 2026 at 03:52:07AM +0000, John Stultz wrote:
>>> From: Christian Loehle <christian.loehle@arm.com>
>>>
>>> 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@redhat.com>
>>> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
>>> Signed-off-by: John Stultz <jstultz@google.com>
>>
>>> ---
>>>  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?

P.S. I dropped this patch and added the following on top of this
series on top of tip:sched/core and nothing has crashed (yet):

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a3003b0f4522..797cb316fcd1 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -101,7 +101,11 @@ static inline struct sched_dl_entity *pi_of(struct sched_dl_entity *dl_se)
 
 static inline bool is_dl_boosted(struct sched_dl_entity *dl_se)
 {
-	return false;
+	struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
+	struct rq *rq = rq_of_dl_rq(dl_rq);
+
+	return sched_proxy_exec() && rq->donor != rq->curr && dl_task_of(dl_se) == rq->donor;
+
 }
 #endif /* !CONFIG_RT_MUTEXES */
 
---

I used AI to generate a module that spawns 100 threads (50 SCHED_DEADLINE,
50 SCHED_OTHER) that does 100000 iterations of yield() in a mutex critical
section and I haven't seen any splats from deadline.c yet.

I do see the deadline threads on the CPU when inspecting
/sys/kernel/debug/sched/debug and things are finishing much faster than
sched_proxy_exec=0 case so I'm assuming it is working similar to the
rt_mutex :-)

-- 
Thanks and Regards,
Prateek