From: Peter Zijlstra <peterz@infradead.org>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Clark Williams <williams@redhat.com>,
arighi@nvidia.com
Subject: Re: [RFC PATCH] sched/deadline: Avoid dl_server boosting with expired deadline
Date: Fri, 31 Oct 2025 14:05:43 +0100 [thread overview]
Message-ID: <20251031130543.GV4068168@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20251030184205.GB2989771@noisy.programming.kicks-ass.net>
On Thu, Oct 30, 2025 at 07:42:05PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 22, 2025 at 12:11:51PM +0200, Gabriele Monaco wrote:
>
> Sorry, finally cycling back to this.
>
> > > So how about something like this for starters?
> > >
> >
> > Thanks Peter for sharing this patch, I run it through my test and the model
> > seems to pass (i.e. no more boosting after deadline). What I found curious
> > however, is that throughout the test, servers went only through replenish
> > events.
> > The system under test is mostly idle (6 periodic dl tasks on a 16 CPUs virtme-ng
> > VM), so I expect not to see any task boosted by the servers, but in 5 minutes I
> > didn't even observe any start/stop for the server.
> >
> > I'm not sure why this is happening, but looking at traces it seems replenish
> > occurs more often and perhaps doesn't let the server stop:
> >
> > <idle>-0 [009] d.h3. 14.312395: (+950124) event_nomiss: -9: idle x dl_replenish_idle -> idle
> > <idle>-0 [009] d.h3. 14.312401: (+6) sched_dl_replenish: comm=server pid=-9 runtime=50000000 deadline=15253307235 yielded=0
> > <idle>-0 [009] d.h3. 15.262771: (+950370) event_nomiss: -9: idle x dl_replenish_idle -> idle
> > <idle>-0 [009] d.h3. 15.262781: (+10) sched_dl_replenish: comm=server pid=-9 runtime=50000000 deadline=16203668554 yielded=0
> > <idle>-0 [009] d.h3. 16.213117: (+950336) event_nomiss: -9: idle x dl_replenish_idle -> idle
> > <idle>-0 [009] d.h3. 16.213123: (+6) sched_dl_replenish: comm=server pid=-9 runtime=50000000 deadline=17154029879 yielded=0
> >
> > Is this expected?
>
> Sort of, that was next on the list. Let me see if I can make it stop a
> little more.
OK, so I've gone over things again and all I got was a comment.
That is, today I think it all works as expected.
The dl_server will stop once the fair class goes idle long enough. Can
you confirm this?
---
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1152,6 +1152,94 @@ static void __push_dl_task(struct rq *rq
/* a defer timer will not be reset if the runtime consumed was < dl_server_min_res */
static const u64 dl_server_min_res = 1 * NSEC_PER_MSEC;
+
+/*
+ * dl_server && dl_defer:
+ * dl_defer_armed = 0
+ * dl_defer_running = 0
+ * dl_throttled = 0
+ *
+ * [1] dl_server_start()
+ * dl_server_active = 1;
+ * enqueue_dl_entity()
+ * update_dl_entity(WAKEUP)
+ * if (!dl_defer_running)
+ * dl_defer_armed = 1;
+ * dl_defer_throttled = 1;
+ * if (dl_throttled && start_dl_timer())
+ * return;
+ * // start server into waiting for zero-laxity
+ *
+ * // deplete server runtime from fair-class
+ * [2] update_curr_dl_se()
+ * if (dl_defer && dl_throttled && dl_runtime_exceeded())
+ * dl_defer_running = 0;
+ * hrtimer_try_to_cancel(); // stop timer
+ * replenish_dl_new_period()
+ * // advance period
+ * dl_throttled = 1;
+ * dl_defer_armed = 1;
+ * start_dl_timer(); // restart timer
+ * // back into waiting for zero-laxity
+ *
+ * // timer actually fires means we have runtime
+ * [4] dl_server_timer()
+ * if (dl_defer_armed)
+ * dl_defer_running = 1;
+ * enqueue_dl_entity(REPLENISH)
+ * replenish_dl_entity()
+ * opt-fwd-period
+ * if (dl_throttled)
+ * dl_throttled = 0;
+ * if (dl_defer_armed)
+ * dl_defer_armed = 0;
+ * __enqueue_dl_entity();
+ * // server queued
+ *
+ * // schedule server
+ * [5] pick_task_dl()
+ * p = server_pick_task();
+ * if (!p)
+ * dl_server_stop()
+ * dequeue_dl_entity();
+ * hrtimer_try_to_cancel();
+ * dl_defer_armed = 0;
+ * dl_throttled = 0;
+ * dl_server_active = 0;
+ * // goto [1]
+ *
+ * // server running
+ * [6] update_curr_dl_se()
+ * if (dl_runtime_exceeded())
+ * dl_throttled = 1;
+ * dequeue_dl_entity();
+ * start_dl_timer();
+ * // replenish-timer
+ *
+ * // goto [2]
+ *
+ * [7] dl_server_timer()
+ * enqueue_dl_entity(REPLENISH)
+ * replenish_dl_entity()
+ * fwd-period
+ * if (dl_throttled)
+ * dl_throttled = 0;
+ * __enqueue_dl_entity();
+ * // goto [5]
+ *
+ * Notes:
+ *
+ * - When there are fair tasks running the most likely loop is [2]->[2].
+ * the dl_server never actually runs, the timer never fires.
+ *
+ * - When there is actual fair starvation; the timer fires and starts the
+ * dl_server. This will then throttle and replenish like a normal DL
+ * task. Notably it will not 'defer' again.
+ *
+ * - When fair goes idle, it will not consume dl_server budget so the server
+ * will start. However, it will find there are no fair tasks to run and
+ * stop itself.
+ */
static enum hrtimer_restart dl_server_timer(struct hrtimer *timer, struct sched_dl_entity *dl_se)
{
struct rq *rq = rq_of_dl_se(dl_se);
next prev parent reply other threads:[~2025-10-31 13:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 12:29 Gabriele Monaco
2025-10-14 9:30 ` Gabriele Monaco
2025-10-14 9:54 ` Peter Zijlstra
2025-10-14 10:05 ` Gabriele Monaco
2025-10-14 10:25 ` Peter Zijlstra
2025-10-14 15:32 ` Gabriele Monaco
2025-10-14 16:01 ` Juri Lelli
2025-10-14 19:33 ` Peter Zijlstra
2025-10-15 5:40 ` Juri Lelli
2025-10-20 14:11 ` Peter Zijlstra
2025-10-22 10:11 ` Gabriele Monaco
2025-10-30 18:42 ` Peter Zijlstra
2025-10-31 13:05 ` Peter Zijlstra [this message]
2025-10-31 13:24 ` Gabriele Monaco
2025-10-31 15:20 ` Peter Zijlstra
2025-10-31 15:41 ` Gabriele Monaco
2025-10-31 15:44 ` Peter Zijlstra
2025-10-31 15:51 ` Gabriele Monaco
2025-11-01 0:00 ` Peter Zijlstra
2025-11-11 9:58 ` Gabriele Monaco
2025-11-11 11:17 ` Peter Zijlstra
2025-11-11 11:24 ` Peter Zijlstra
2025-11-11 11:37 ` [tip: sched/core] sched/deadline: Fix dl_server stop condition tip-bot2 for Peter Zijlstra
2025-11-01 0:08 ` [RFC PATCH] sched/deadline: Avoid dl_server boosting with expired deadline Peter Zijlstra
2025-11-01 8:43 ` Gabriele Monaco
2025-11-11 11:37 ` [tip: sched/core] sched/deadline: Fix dl_server time accounting 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=20251031130543.GV4068168@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=arighi@nvidia.com \
--cc=gmonaco@redhat.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=williams@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
all inboxes | Powered by JetHome®