From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from serv15.avernis.de (serv15.avernis.de [176.9.89.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58CD426E165 for ; Fri, 8 May 2026 12:06:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=176.9.89.163 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778242009; cv=none; b=tZy2ISF9eX193wAyoN+0XR3lvOLWaFR9NwLzQzX9imwiSztIj42fEPv84R3jM0GiMaAzDrVmrQY/DRiaIEu7z3RhLDi7aFQlxO0szXuBmMUeWpiBJ1D36ZyQydNsOF0/sgSkbd7WOU73S/Mrz46r1qOGjXokCSyzccq8QkmVR9U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778242009; c=relaxed/simple; bh=hQLKDgYvhwOegAX4ijMijJyikHw1RJAqU2s2P3Yiggs=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type; b=EiCJ3bqev1EpelxK7m7JAQSgL43GuICvdSF5+zF8aBakzeq0FjWht2xEbtcx3R9ZkxL/z0iDtwLdT+924Vu5Sh0EQOiLyMCXlRZM92rhyvtsnW1Nu4c1Q9wvRSaNjWvY+BFIIjHINMULpxrlRlJYQ1tar6QsrFw/1UbOxKh2vhY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=umbiko.net; spf=none smtp.mailfrom=umbiko.net; dkim=pass (1024-bit key) header.d=umbiko.net header.i=@umbiko.net header.b=n/fcqu3k; arc=none smtp.client-ip=176.9.89.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=umbiko.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=umbiko.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=umbiko.net header.i=@umbiko.net header.b="n/fcqu3k" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=umbiko.net; s=mail; t=1778242004; bh=hQLKDgYvhwOegAX4ijMijJyikHw1RJAqU2s2P3Yiggs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=n/fcqu3k+ZwxCFd6JceEWc8ykyPzeHIjE3okDeT/trdtUcyHDduYUTmREEEokqClO a8yFadOtRbQGKoipJjh+SH8toGN8kHM7aVNF1Xhj3jisd2kbZxpyCwxXRIzVI0s6Kp rlpknWottd9r4W75uNZeQyKcxmf/bLT7r0/xNBI4= Received: by serv15.avernis.de (Postfix) with ESMTPSA id A02F2BDE4D69; Fri, 08 May 2026 14:06:43 +0200 (CEST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Fri, 08 May 2026 12:06:43 +0000 From: Andreas Ziegler To: Christian Loehle Cc: Peter Zijlstra , Juri Lelli , linux-kernel@vger.kernel.org, Dietmar Eggemann Subject: Re: sched/deadline: Use revised wakeup rule for dl_server In-Reply-To: References: <496e4b3329fe258da9618b9f05b18fcf@umbiko.net> Message-ID: <97d9e04fd9d222f1a64f1ecfda8b81d7@umbiko.net> X-Sender: br025@umbiko.net Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 1.4.3 at serv15.avernis.de X-Virus-Status: Clean 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