All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: regressions@lists.linux.dev, Juri Lelli <juri.lelli@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	stable@vger.kernel.org, linux-rt-users@vger.kernel.org,
	Mike Galbraith <efault@gmx.de>,
	Lukas Beckmann <lbckmnn@mailbox.org>
Subject: Re: [REGRESSION] 6.12.y: d66792919d4f (sched/deadline: Use revised wakeup rule for dl_server) causes latencies up to 50ms with PREEMPT_RT
Date: Thu, 21 May 2026 12:49:52 -0400	[thread overview]
Message-ID: <ag83sNErxAAZorCG@laps> (raw)
In-Reply-To: <36acb7e8-1fae-4c6d-8145-a29685007a76@leemhuis.info>

On Thu, May 21, 2026 at 09:32:32AM +0200, Thorsten Leemhuis wrote:
>On 5/16/26 21:50, Lukas Beckmann wrote:
>> On Tue, May 12, 2026 at 12:08:49AM +0200, Lukas Beckmann wrote:
>>> On 5/11/26 16:21, Sasha Levin wrote:
>>>> Thanks for the detailed report. Before I revert d66792919d4f from 6.12.y,
>>>> I'd like to confirm whether the underlying issue is the missing dl_server
>>>> rework chain on 6.12.y rather than the revised wakeup rule itself.
>>>>
>>>> Mike's reply notes that his local 6.12-rt tree carrying the following
>>>> three commits in cannot reproduce, while the same tree without them
>>>> reproduces quickly:
>>>>
>>>>    cccb45d7c429 ("sched/deadline: Less agressive dl_server handling")
>>>>    4ae8d9aa9f9d ("sched/deadline: Fix dl_server getting stuck")
>>>>    a3a70caf7906 ("sched/deadline: Fix dl_server behaviour")
>>>>
>>>> d66792919d4f's upstream commit message explicitly says it relies on the
>>>> state established by a3a70caf7906, and none of the three are in 6.12.y.
>>>>
>>>> Could you give those three commits a spin on top of 6.12.y (keeping
>>>> d66792919d4f in place) and see whether the latency goes away?
>>>
>>> If I apply the three commits on 6.12.y, the latencies indeed go away.
>>> This is running for a few hours now, and the latencies showed up after 30
>>> minutes tops, with plain 6.12.y before.
>>> I will leave this running.
>>
>> Cyclictest is still running and looking good (latency-wise).
>> How should we proceed?
>
>Sasha, just wondering: is this still in your queue? It sounds like a
>clear case to pick those three up for 6.12.y (everybody: please correct
>me if I'm wrong). Or are you busy and should we ask Greg to pick them up?

Nope, sorry, I got sidetracked by a large series of commits from the merge window.

I'll plan to queue this up for the next release. It'll be even better if
someone can send us a more "official" backport request, ideally with a
tested-by too :)

-- 
Thanks,
Sasha

  reply	other threads:[~2026-05-21 16:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-10 20:57 [REGRESSION] 6.12.y: d66792919d4f (sched/deadline: Use revised wakeup rule for dl_server) causes latencies up to 50ms with PREEMPT_RT Lukas Beckmann
2026-05-11  5:50 ` Mike Galbraith
2026-05-11 14:21 ` Sasha Levin
2026-05-11 15:30   ` Mike Galbraith
2026-05-11 22:08   ` Lukas Beckmann
2026-05-16 19:50     ` Lukas Beckmann
2026-05-21  7:32       ` Thorsten Leemhuis
2026-05-21 16:49         ` Sasha Levin [this message]
2026-05-22 21:35           ` Lukas Beckmann

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=ag83sNErxAAZorCG@laps \
    --to=sashal@kernel.org \
    --cc=efault@gmx.de \
    --cc=juri.lelli@redhat.com \
    --cc=lbckmnn@mailbox.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.