From: Andreas Ziegler <br025@umbiko.net>
To: Christian Loehle <christian.loehle@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
linux-kernel@vger.kernel.org,
Dietmar Eggemann <dietmar.eggemann@arm.com>
Subject: Re: sched/deadline: Use revised wakeup rule for dl_server
Date: Fri, 08 May 2026 12:06:43 +0000 [thread overview]
Message-ID: <97d9e04fd9d222f1a64f1ecfda8b81d7@umbiko.net> (raw)
In-Reply-To: <afd67ad9-c77e-4c19-94b7-fa76e09bda9e@arm.com>
Hi Christian,
On 2026-05-08 09:20, Christian Loehle wrote:
> 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?
Actually this is a very stripped-down system. The 'performance' cpufreq
governor is the only one compiled in, the processor cores run on a fixed
frequency. CONFIG_PM_OPP is not set.
Removing the frequency constraint and using 'powersave' governor lets
the latency values rise generally, but the anomaly under write loads
persists. The cpu frequency does not change, but remains stuck on the
lowest level.
--- Benchmarking simulated cpu of Audio real time in the presence of
simulated ---
Load Latency +/- SD median max [100n] Desired CPU Deadlines met [%]
None 238.7 +/- 31.416 229 405
Video 228.6 +/- 13.668 226 291
X 247.8 +/- 29.196 239 425
Burn 222.6 +/- 30.631 215 348
Write 1214.8 +/- 20397 369500411 99.8 99.8
Read 393.9 +/- 21.375 394 476
Ring 250.3 +/- 27.59 241 365
Compile 411.2 +/- 23.41 411 474
401.0 +/- 7218.2 500411
Same with 'schedutil' governor; the cpu frequency adjusts with the load.
--- Benchmarking simulated cpu of Audio real time in the presence of
simulated ---
Load Latency +/- SD median max [100n] Desired CPU Deadlines met [%]
None 200.9 +/- 57.332 208 431
Video 136.2 +/- 23.784 136 250
X 172.3 +/- 59.286 174 404
Burn 104.1 +/- 22.847 97 247
Write 5337.5 +/- 49960 286500394 99 99
Read 300.5 +/- 18.65 301 359
Ring 119.8 +/- 15.8 115 196
Compile 282.7 +/- 25.056 280 469
831.7 +/- 17746 500394
Kind regards,
Andreas
next prev parent reply other threads:[~2026-05-08 12:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 8:09 sched/deadline: Use revised wakeup rule for dl_server Andreas Ziegler
2026-05-08 9:20 ` Christian Loehle
2026-05-08 12:06 ` Andreas Ziegler [this message]
2026-05-08 14:13 ` Christian Loehle
2026-05-09 11:42 ` Andreas Ziegler
2026-05-11 9:47 ` Christian Loehle
2026-05-11 12:37 ` Andreas Ziegler
2026-05-11 12:46 ` Juri Lelli
2026-05-11 14:13 ` Andreas Ziegler
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=97d9e04fd9d222f1a64f1ecfda8b81d7@umbiko.net \
--to=br025@umbiko.net \
--cc=christian.loehle@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/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