Re: sched/deadline: Use revised wakeup rule for dl_server

[Christian Loehle <christian.loehle@arm.com>]

On 5/8/26 09:09, Andreas Ziegler wrote:
> Linux kernel version: 6.12
>   CONFIG_PREEMPT_RT (w/ PREEMPT_RT patch applied)
> Architecture: aarch64
> Platform: Raspberry Pi 4
> 
> Hi everyone,
> 
> Commit d66792919d4f (sched/deadline: Use revised wakeup rule for dl_server) [1] introduced a marked degradation in scheduling latency for real-time tasks in the presence of heavy I/O load.
> 
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1079,7 +1079,7 @@ static void update_dl_entity(struct sched_dl_entity *dl_se)
>      if (dl_time_before(dl_se->deadline, rq_clock(rq)) ||
>          dl_entity_overflow(dl_se, rq_clock(rq))) {
> 
> -        if (unlikely(!dl_is_implicit(dl_se) &&
> +        if (unlikely((!dl_is_implicit(dl_se) || dl_se->dl_defer) &&
>                   !dl_time_before(dl_se->deadline, rq_clock(rq)) &&
>                   !is_dl_boosted(dl_se))) {
>              update_dl_revised_wakeup(dl_se, rq);
> 
> This was observed using a modified version of Con Kolivas' interactivity benchmark [2]; kernel bisection eventually pointed to the above mentioned commit.
> 
> Benchmark results before d66792919d4f:
> 
> --- Benchmarking simulated cpu of Audio real time in the presence of simulated ---
> Load    Latency +/- SD   median  max [100n]    Desired CPU  Deadlines met [%]
> None      76.6 +/- 8.3654    76  166
> Video      78.5 +/- 3.9433    78  107
> X      76.4 +/- 8.123     75  157
> Burn      72.0 +/- 6.4733    71  127
> Write     255.3 +/- 26.627   252  331
> Read     226.6 +/- 12.38    227  262
> Ring      84.2 +/- 6.6207    83  125
> Compile     225.3 +/- 23.949   222  328
> 
>      136.8 +/- 78.462        331
> 
> Benchmark results after d66792919d4f:
> 
> --- Benchmarking simulated cpu of Audio real time in the presence of simulated ---
> Load    Latency +/- SD   median  max [100n]    Desired CPU  Deadlines met [%]
> None      68.4 +/- 9.7864    67  169
> Video      74.4 +/- 3.724     74   97
> X      72.0 +/- 6.5681    71  129
> Burn      66.9 +/- 5.9059    66  117
> Write    9576.9 +/- 67639    250500418        98.1         98.1
> Read     209.3 +/- 11.018   209  267
> Ring      80.5 +/- 8.0993    78  125
> Compile     239.0 +/- 29.447   234  372
> 
>     1298.4 +/- 24118       500418
> 
> Reverting this commit obviously solves the issue for me. I have no idea why this issue appears exclusively with heavy write loads in the background.
> 
> Is this a scheduler issue, or rather something in the background?
> 

Hi Andreas,
You're using cpufreq schedutil for your tests I'm assuming?
Is there a difference in cpufreq behavior (avg cpufreq or OPP residencies?)
Does the regression also happen on powersave/performance governor?