public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: John Stultz <jstultz@google.com>
Cc: soolaugust@gmail.com, juri.lelli@redhat.com, mingo@redhat.com,
	linux-kernel@vger.kernel.org, zhidao su <suzhidao@xiaomi.com>,
	Andrea Righi <arighi@nvidia.com>
Subject: Re: [PATCH] sched/deadline: Fix stale dl_defer_running in update_dl_entity() if-branch
Date: Sat, 4 Apr 2026 00:46:10 +0200	[thread overview]
Message-ID: <20260403224610.GJ2872@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CANDhNCpqiHj0ssKgSkMaYbZ_GTqBd2zk2X5sBBJbCEhCurevnw@mail.gmail.com>

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.

  reply	other threads:[~2026-04-03 22:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02 13:30 [PATCH] sched/deadline: Fix stale dl_defer_running in dl_server else-branch soolaugust
2026-04-03  0:05 ` John Stultz
2026-04-03  1:30   ` John Stultz
2026-04-03  8:12     ` [PATCH] sched/deadline: Fix stale dl_defer_running in update_dl_entity() if-branch soolaugust
2026-04-03 13:42       ` Peter Zijlstra
2026-04-03 13:58         ` Andrea Righi
2026-04-03 19:31         ` John Stultz
2026-04-03 22:46           ` Peter Zijlstra [this message]
2026-04-03 22:51             ` John Stultz
2026-04-03 22:54               ` John Stultz
2026-04-04 10:22             ` Peter Zijlstra
2026-04-05  8:37               ` zhidao su
2026-04-06 20:01               ` John Stultz
2026-04-06 20:03                 ` John Stultz
2026-04-07 12:22               ` Juri Lelli
2026-04-07 15:00                 ` Peter Zijlstra
2026-04-08 11:20               ` [tip: sched/urgent] sched/deadline: Use revised wakeup rule for dl_server tip-bot2 for Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260403224610.GJ2872@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=arighi@nvidia.com \
    --cc=jstultz@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=soolaugust@gmail.com \
    --cc=suzhidao@xiaomi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox