A special flag of the deadline entities, the 'dl_defer' flag, is explicitly
documents changing the behaviour of deadline tasks and servers to the special
deferred behaviour that replenishes and unthrottles the linked dl entity just in
time so it does not miss its deadline.

Currently, this behaviour is only used by fair-servers (and ext-servers), while
regular tasks use the original CBS (Constant Bandwidth Server) rules.

The bug (and fix) which follows is of interest to those deadline server entities
which do not request the deferred behaviour (i.e., dl_defer = 0):
whenever a non-deferred deadline entity expends all of its runtime it must start
the replenishment timer or, if the wake-up instant is too close to the current
time, the entity must be simply re-enqueued and its runtime replenished.
Currently, the 'dl_defer' flag is ignored when replenishing any deadline server,
defaulting to the deferred behaviour, while this fix correctly addresses the
issue.

Unfortunately, no testing of this bugfix is possible as there are currently no
deadline servers which use the standard non-deferred behaviour. This bug was
discovered during the development of the Hierarchical CBS patch
(https://lore.kernel.org/all/20251201124205.11169-1-yurand2000@gmail.com/) which
makes extensive use of the non-deferred servers.

Thanks for your support and have a nice day,
Yuri

Signed-off-by: Yuri Andriaccio <yurand2000@gmail.com>
---
 kernel/sched/deadline.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d08b00429323..19e63d1307b7 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1523,8 +1523,12 @@ static void update_curr_dl_se(struct rq *rq, struct sched_dl_entity *dl_se, s64

 		if (unlikely(is_dl_boosted(dl_se) || !start_dl_timer(dl_se))) {
 			if (dl_server(dl_se)) {
-				replenish_dl_new_period(dl_se, rq);
-				start_dl_timer(dl_se);
+				if (dl_se->dl_defer) {
+					replenish_dl_new_period(dl_se, rq);
+					start_dl_timer(dl_se);
+				} else {
+					enqueue_dl_entity(dl_se, ENQUEUE_REPLENISH);
+				}
 			} else {
 				enqueue_task_dl(rq, dl_task_of(dl_se), ENQUEUE_REPLENISH);
 			}

base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
--
2.53.0

Hi Yuri,

On 20/04/26 18:34, Yuri Andriaccio wrote:
> A special flag of the deadline entities, the 'dl_defer' flag, is explicitly
> documents changing the behaviour of deadline tasks and servers to the special
> deferred behaviour that replenishes and unthrottles the linked dl entity just in
> time so it does not miss its deadline.

Maybe rephrase to make it more direct, like "The dl_defer flag is used
..."?

> Currently, this behaviour is only used by fair-servers (and ext-servers), while
> regular tasks use the original CBS (Constant Bandwidth Server) rules.
> 
> The bug (and fix) which follows is of interest to those deadline server entities
> which do not request the deferred behaviour (i.e., dl_defer = 0):
> whenever a non-deferred deadline entity expends all of its runtime it must start
> the replenishment timer or, if the wake-up instant is too close to the current
> time, the entity must be simply re-enqueued and its runtime replenished.
> Currently, the 'dl_defer' flag is ignored when replenishing any deadline server,
> defaulting to the deferred behaviour, while this fix correctly addresses the
> issue.

I think we might want to make the above more imperative (don't use "this
fix", etc). Simply state what the fix does.

> Unfortunately, no testing of this bugfix is possible as there are currently no
> deadline servers which use the standard non-deferred behaviour. This bug was
> discovered during the development of the Hierarchical CBS patch
> (https://lore.kernel.org/all/20251201124205.11169-1-yurand2000@gmail.com/) which
> makes extensive use of the non-deferred servers.
> 
> Thanks for your support and have a nice day,
> Yuri

The above (from "Unfortunately..) doesn't belong to the changelog, you
can put it under the --- region in your next version if you want to add
comments of this type.

> Signed-off-by: Yuri Andriaccio <yurand2000@gmail.com>
> ---

Apart from the suggestions above, the fix makes sense to me (and I trust
it works with the rest of HCBS patches you are working on).

Thanks!
Juri