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

[Andreas Ziegler]

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?

Kind regards,
Andreas

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.86&id=d66792919d4f7bd326dfd8c21d019f7c5d4ef05c
[2] https://github.com/ckolivas/interbench