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

[Peter Zijlstra]

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.