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

[John Stultz]

On Sat, Apr 4, 2026 at 3:22 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Sat, Apr 04, 2026 at 12:46:10AM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 03, 2026 at 12:31:19PM -0700, John Stultz wrote:
> >
> > > Using a 8 cpu VM with CONFIG_SCHED_PROXY_EXEC disabled:
> > >
> > > With commit 115135422562 ("sched/deadline: Fix 'stuck' dl_server")
> > > reverted, I see the (expected, maybe) behavior where the starvation
> > > lasts ~1second, then dl_server allows all the threads to spawn right
> > > away, and then the test runs for 10 seconds.
> > >
> > > See perfetto chart:
> > >   https://ui.perfetto.dev/#!/?s=a729fd2dd4b224d6335c5b2e727dc1a1c302c11a
> > > (click the Kernel-threads track and scroll down to see the test
> > > threads named referee/defense/offense/crazy-fan)
> > >
> > > With commit 115135422562 ("sched/deadline: Fix 'stuck' dl_server")
> > > applied, it seems the dl_server boosting the kthreadd spawning is much
> > > more staggered. Again we spin up NR_CPU low priority threads, and
> > > there's  ~1second of starvation, then we spawn one of the mid threads,
> > > and another second delay, then there's a two second delay befofe we
> > > get the third running, then we get a small burst of 5 threads at once,
> > > then it falls back to 1 second or more per thread as it spawns off the
> > > rest. All in all it takes ~44 seconds just to spawn the threads before
> > > running the test.
> > >
> > > Perfetto chart:
> > >   https://ui.perfetto.dev/#!/?s=ab8e487375d0c82ceea478ee4534a7189269c0d4
> > >
> > > With higher cpu counts (64), the test effectively prevents the system
> > > from booting (trips the hung task watchdog).
> > >
> > > I haven't really diagnosed the issue, but it feels a little like the
> > > dl_server is boosting until the fair rq is empty but then giving up
> > > the rest of its time, so if a fair task runs repeatedly but for a very
> > > short period of time, it won't get to run again until the next
> > > dl_server period? Causing this rate-limiting one-task-per-second
> > > effect for thread spawning? I still need to stare at the dl_server
> > > logic some more.
> >
> > I'm getting a sense of deja-vu here. Didn't we cure this once before?
> >
> > I'll go stare at this somewhere next week I suppose -- we have a long
> > weekend here.
>
> Random brain wave...
>
> Since the dl_server is LLF (deferred), it will pretty much always trip
> the dl_entity_overflow() when interrupted, right? Does it make sense to
> use the revised wake-up rule for it, when appropriate?
>
> ---
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index d08b00429323..674de6a48551 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1027,7 +1027,7 @@ static void update_dl_entity(struct sched_dl_entity *dl_se)
>         if (dl_time_before(dl_se->deadline, rq_clock(rq)) ||
>             dl_entity_overflow(dl_se, rq_clock(rq))) {
>
> -               if (unlikely(!dl_is_implicit(dl_se) &&
> +               if (unlikely((!dl_is_implicit(dl_se) || dl_se->dl_defer) &&
>                              !dl_time_before(dl_se->deadline, rq_clock(rq)) &&
>                              !is_dl_boosted(dl_se))) {
>                         update_dl_revised_wakeup(dl_se, rq);

Hey Peter!
  So yeah, this does seem to resolve the main issue with the test.
After ~1second of the initial low-priority RT tasks starving the CPU,
all the other threads spawn in quick succession, and it doesnt' delay
us getting to run the test.

The only detail I might mention, is that looking at perfetto charts,
comparing this fix vs reverting 115135422562 ("sched/deadline: Fix
'stuck' dl_server"), is that during the ksched_football test (where we
have a lot of RT spinners running), other very short-running non-RT
kworker threads seem to have more 1 second delays where they are
runnable with this solution:
  https://ui.perfetto.dev/#!/?s=fbc54ab8b823fc3d906eb16b9bcfb5b1fcbadf09

With 115135422562 reverted, they seem to get to run fairly quickly
despite the RT spinners.
  https://ui.perfetto.dev/#!/?s=35aa5b8e395ee5cf6fe22cc7f8c7e0cd8f4fcec5

This may be in fact the issue being fixed with 115135422562 (I still
find the details opaque), and I don't see any delays much larger than
a second. So it probably isn't an issue, but just wanted to highlight
it.

thanks
-john