public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Tejun Heo <tj@kernel.org>, Joel Fernandes <joelagnelf@nvidia.com>,
	David Vernet <void@manifault.com>,
	Changwoo Min <changwoo@igalia.com>,
	Daniel Hodges <hodgesd@meta.com>,
	sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] sched/deadline: Reset dl_server execution state on stop
Date: Mon, 26 Jan 2026 22:26:51 +0100	[thread overview]
Message-ID: <aXfcGynN92kyw5Co@gpd4> (raw)
In-Reply-To: <cc33e6e3-3ffe-4ebc-a2e3-7dd7afe13538@redhat.com>

On Mon, Jan 26, 2026 at 04:56:52PM +0000, Gabriele Monaco wrote:
> 2026-01-26T16:30:45Z Andrea Righi <arighi@nvidia.com>:
> 
> > Hi Gabriele,
> >
> > On Mon, Jan 26, 2026 at 03:20:12PM +0100, Gabriele Monaco wrote:
> 
> >> In the sequence you described above, I wonder why the enqueue is never
> >> replenishing. As far as I understand the runtime should remain <= 0 only as long
> >> as the enqueue occurs before the deadline, after that it should simply replenish
> >> a new period (pushing deadline and restoring runtime).
> >>
> >> What am I missing here?
> >
> > Replenishment is not triggered directly by enqueueing, but by the
> > deferral/replenishment timer. In this case the timer is never armed: stale
> > dl_defer_running makes the enqueue path believe the server is already in
> > the running phase, which suppresses deferral arming, causing
> > start_dl_timer() to be skipped.
> >
> 
> Hi Andrea,
> 
> thanks for the clarification, but I think I observed the enqueue/dl_server_start replenishing a new period when running.
> 
> Something like:
> dl_server_start()
>   enqueue_dl_entity(ENQUEUE_WAKEUP)
>     update_dl_entity()
>       replenish_dl_new_period()
> 
> should happen if the deadline is in the past, unless I'm missing some condition down the road.
> 
> Still if it starts before the deadline, the server is going to get throttled as you observed, and perhaps since in your tests the CPU isn't idle, we don't stop the server after that dequeue and then we never replenish after the deadline (because we never start and as you mentioned, the timer is not armed).
> 
> Can this be what you're observing?

Yes, I think it matches what I'm observing.

In my case the server is (re)started before the deadline, so it immediately
runs with exhausted runtime, gets throttled, and is dequeued. Since the CPU
isn't idle, we don't hit a path that would stop the server cleanly and
reset its execution state.

At that point, because dl_defer_running is still set, the restart path
assumes the server is already in the running phase and skips arming the
deferral/replenishment timer. Therefore, once the deadline passes there is
no remaining trigger to replenish a new period and the server gets stuck in
a throttled-but-running state.

Thanks,
-Andrea

  reply	other threads:[~2026-01-26 21:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 16:16 [PATCH v2] sched/deadline: Reset dl_server execution state on stop Andrea Righi
2026-01-23 16:22 ` Juri Lelli
2026-01-26 14:20 ` Gabriele Monaco
2026-01-26 16:30   ` Andrea Righi
2026-01-26 16:56     ` Gabriele Monaco
2026-01-26 21:26       ` Andrea Righi [this message]
2026-01-27  8:52         ` Gabriele Monaco
2026-01-27 14:18           ` Andrea Righi
2026-01-27 16:00             ` Gabriele Monaco
2026-01-27 18:54               ` Andrea Righi
2026-01-28  9:50                 ` Gabriele Monaco
2026-01-28 13:41                   ` Andrea Righi
2026-01-29 11:48                     ` gmonaco
2026-01-29 17:32                       ` Andrea Righi
2026-01-30  7:30                         ` Juri Lelli
2026-01-30 12:24                     ` Peter Zijlstra
2026-01-30 12:26                       ` Peter Zijlstra
2026-01-30 12:41                         ` Peter Zijlstra
2026-01-30 15:52                           ` Juri Lelli
2026-01-30 16:25                           ` Andrea Righi
2026-01-30 16:40                             ` Peter Zijlstra
2026-01-30 16:46                               ` Andrea Righi
2026-01-30 22:12                           ` [tip: sched/urgent] sched/deadline: Fix 'stuck' 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=aXfcGynN92kyw5Co@gpd4 \
    --to=arighi@nvidia.com \
    --cc=bsegall@google.com \
    --cc=changwoo@igalia.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gmonaco@redhat.com \
    --cc=hodgesd@meta.com \
    --cc=joelagnelf@nvidia.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=void@manifault.com \
    --cc=vschneid@redhat.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