From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7670D1397 for ; Fri, 8 May 2026 14:13:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778249631; cv=none; b=lRqcq6wRvi3+cpQjGKynpw2RKOhwJAg8z8aUTRLov23O04sgWhWlecq4lsp7C69SdyafxHP6i2Fwc4IDZyBJw/IwLEZ91m9p5XpXKlucNwQu0Z4E4ohhKym1SshW53VnFBJLKoO4m1aYUTfgKLeOfnPCK2C35ArPBqcS+OrdNUY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778249631; c=relaxed/simple; bh=F52XHb41Ds622apAW8Rz2P06dhbx/Nino0bOkqdjN7g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dRc6Zw9pW22QdgusBFjT5aP7Wn3JB0atyLfwQocDGVLxY1MHROqMPh4tb4UBvb/+V/2MtR5TYDzFsskNZykUn70pwIbjn/zuBnZzwiJ5vmV7QeQgKd60nylIfCtJXcplvBlvVGdC4d5E9LlzhSs8YSh0wxEx8b/pxcaNGY4wp2w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=XtoWW9cy; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="XtoWW9cy" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 67B391D34; Fri, 8 May 2026 07:13:44 -0700 (PDT) Received: from [10.57.89.33] (unknown [10.57.89.33]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1DEE83F763; Fri, 8 May 2026 07:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778249629; bh=F52XHb41Ds622apAW8Rz2P06dhbx/Nino0bOkqdjN7g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=XtoWW9cyY4COY40AHO/Z4H2J/ge9yzNU70UuvpO/bsgqQ+bocUkTa3vQV1fHck2Io pXlcwSHxg+ttbPafIjwXfCLnQvPsw7ILWsZWWvTuptUWeQ+5XJgiCFVwr1bMpeEHD7 F5c8zbUR4UR7jpr8D0OALr+HtdVL5LIMYJRCVp8E= Message-ID: Date: Fri, 8 May 2026 15:13:45 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: sched/deadline: Use revised wakeup rule for dl_server To: Andreas Ziegler Cc: Peter Zijlstra , Juri Lelli , linux-kernel@vger.kernel.org, Dietmar Eggemann , John Stultz References: <496e4b3329fe258da9618b9f05b18fcf@umbiko.net> <97d9e04fd9d222f1a64f1ecfda8b81d7@umbiko.net> Content-Language: en-US From: Christian Loehle In-Reply-To: <97d9e04fd9d222f1a64f1ecfda8b81d7@umbiko.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 5/8/26 13:06, Andreas Ziegler wrote: > 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. That certainly makes the analysis easier. I couldn't reproduce the issue so far on my system but it does seem like the dl server would get potentially unbounded running time with very frequent starting and stopping of the dlserver (which presumably happens because of the writeback) reset the runtime, which then leads to your 25s observed latency. Peter, how is the revised wakeup rule supposed to behave here? > [snip]