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 57D6C39EF2C for ; Fri, 8 May 2026 09:20:27 +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=1778232030; cv=none; b=F5tXg0YQR/GKXjY/Bu3E5BFu4EvLB8Phtvve8uZ6joG0I89nWJwlIMGVcWXyODu5Qzu/Cx7dj39rhkmIDBLD7MiIUmNm97vkoiY5Ob0zPnjUaSJi+cfhylT0DPLAPOrnaAAPWo0vFoHKLV3easRs22GubmfEUSVWm2tuEGuCMGc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778232030; c=relaxed/simple; bh=DpqIZBEChzXWr9RzRlOYXbhDvzr2YKN7QX7OW2WpxMI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LvrS9Llo4ckpHHZWL6DF56Sbu2E0biROnZSTT2TMZsIUlpsPAGCVe+dZ2VyrVWUnSFE380vkvAR8WvcUbyASO/PPTWXcsyrbLEkOUwM5kUbAKEe/nDei6diD4ARQZfd2q7dwVdF7kNV5bO2lI+omBoCquJw2fUUBub0YqE7B7s0= 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=OLt3uZ6B; 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="OLt3uZ6B" 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 D811D1BCA; Fri, 8 May 2026 02:20:20 -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 3570B3F7B4; Fri, 8 May 2026 02:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778232026; bh=DpqIZBEChzXWr9RzRlOYXbhDvzr2YKN7QX7OW2WpxMI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OLt3uZ6B1ZUZWMK/xbrJuypIuInU93r/vUFgEUTfM9ee/YS+FjRzBZwRdP0RayUo/ 2+aKr+rtWngF8wHc/EwVM386axmN5GTMIz8ng+Ciym7AIInpRxXsA0lgPCkrK0gC0V rdEkzoukmPLab3xD7ls6DEklzHWqBxCf+VvH+pQI= Message-ID: Date: Fri, 8 May 2026 10:20:22 +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 , Peter Zijlstra , Juri Lelli Cc: linux-kernel@vger.kernel.org, Dietmar Eggemann References: <496e4b3329fe258da9618b9f05b18fcf@umbiko.net> Content-Language: en-US From: Christian Loehle In-Reply-To: <496e4b3329fe258da9618b9f05b18fcf@umbiko.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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?