mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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);

  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®