The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

  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