Re: [PATCH] sched/deadline: Fix stale dl_defer_running in update_dl_entity() if-branch

[Andrea Righi <arighi@nvidia.com>]

Hello,

On Fri, Apr 03, 2026 at 03:42:56PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 03, 2026 at 04:12:15PM +0800, soolaugust@gmail.com wrote:
> > From: zhidao su <suzhidao@xiaomi.com>
> > 
> > commit 115135422562 ("sched/deadline: Fix 'stuck' dl_server") added a
> > dl_defer_running = 0 reset in the if-branch of update_dl_entity() to
> > handle the case where [4] D->A is followed by [1] A->B (lapsed
> > deadline). The intent was to ensure the server re-enters the zero-laxity
> > wait when restarted after the deadline has passed.
> > 
> > With Proxy Execution (PE), RT tasks proxied through the scheduler appear
> > to trigger frequent dl_server_start() calls with expired deadlines. When
> > this happens with dl_defer_running=1 (from a prior starvation episode),
> > Peter's fix forces the fair_server back through the ~950ms zero-laxity
> > wait each time.
> > 
> > In our testing (virtme-ng, 4 CPUs, 4G RAM, ksched_football):
> >   With this fix:    ~1s for all players to check in
> >   Without this fix: ~28s for all players to check in
> > 
> > The issue appears to be that the clearing in update_dl_entity()'s
> > if-branch is too aggressive for the PE use case.
> > replenish_dl_new_period() already handles this via its internal guard:
> > 
> >   if (dl_se->dl_defer && !dl_se->dl_defer_running) {
> >       dl_se->dl_throttled = 1;
> >       dl_se->dl_defer_armed = 1;
> >   }
> > 
> > When dl_defer_running=1 (starvation previously confirmed by the
> > zero-laxity timer), replenish_dl_new_period() skips arming the
> > zero-laxity timer, allowing the server to run directly. This seems
> > correct: once starvation has been confirmed, subsequent start/stop
> > cycles triggered by PE should not re-introduce the deferral delay.
> > 
> > Note: this is the same change as the HACK revert in John's PE series
> > (679ede58445 "HACK: Revert 'sched/deadline: Fix stuck dl_server'"),
> > but with the rationale documented.
> > 
> > The state machine comment is updated to reflect the actual behavior of
> > replenish_dl_new_period() when dl_defer_running=1.
> > 
> > Signed-off-by: zhidao su <suzhidao@xiaomi.com>
> > ---
> >  kernel/sched/deadline.c | 12 +++---------
> >  1 file changed, 3 insertions(+), 9 deletions(-)
> > 
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index 01754d699f0..30b03021fce 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -1034,12 +1034,6 @@ static void update_dl_entity(struct sched_dl_entity *dl_se)
> >  			return;
> >  		}
> >  
> > -		/*
> > -		 * When [4] D->A is followed by [1] A->B, dl_defer_running
> > -		 * needs to be cleared, otherwise it will fail to properly
> > -		 * start the zero-laxity timer.
> > -		 */
> > -		dl_se->dl_defer_running = 0;
> >  		replenish_dl_new_period(dl_se, rq);
> >  	} else if (dl_server(dl_se) && dl_se->dl_defer) {
> >  		/*
> 
> This cannot be right; it will insta break Andrea's test case again.

I confirm that with this applied the sched_ext rt_stall selftest starts failing:

$ sudo ./runner -t rt_stall
...
# Runtime of EXT task (PID 2260) is 0.010000 seconds
# Runtime of RT task (PID 2261) is 5.000000 seconds
# EXT task got 0.20% of total runtime
not ok 4 FAIL: EXT task got less than 4.00% of runtime
[  218.923834] sched_ext: BPF scheduler "rt_stall" disabled (unregistered from user space)
# Planned tests != run tests (1 != 4)

> 
> And I cannot make sense of your explanation; how does PE cause what to
> happen? You mention PROXY_WAKING, this then means proxy_force_return().
> 
> I suspect whatever it is you're seeing will go away once we delete that
> thing, see this discussion:
> 
>   https://lkml.kernel.org/r/20260402155055.GV3738010@noisy.programming.kicks-ass.net
> 

Thanks,
-Andrea