From: Juri Lelli <juri.lelli@redhat.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Linux warns `sched: DL replenish lagged too much`
Date: Thu, 20 Feb 2025 14:35:05 +0100 [thread overview]
Message-ID: <Z7cvifR-y0CWK1e6@jlelli-thinkpadt14gen4.remote.csb> (raw)
In-Reply-To: <6ebe1130-0143-4388-9d69-ead0bf1fddf9@molgen.mpg.de>
Dear Paul,
On 20/02/25 11:47, Paul Menzel wrote:
> Dear Linux folks,
>
>
> On the Intel Kaby Lake laptop Dell XPS 13 with Linux
> 6.14.0-rc3-00060-g6537cfb395f3, waking it up from ACPI S3 with an LMP USB-C
> mini dock connected, that had an Ethernet cable and a power adapter plugged
> in, everything was lagging, and also the video in the opened Firefox Nightly
> browser lagged quite a bit. This has happened in the past, but not that bad
> and long. Today for the first time, Linux logged the warning below:
>
> sched: DL replenish lagged too much
>
> (This is from `kernel/sched/deadline.c`.)
>
> I have no idea, if it’s related to the hardware itself, that causes it to
> lag, that a suspend/resume cycle fixes, or if it’s related to the USB-C
> controller that has bugs in that early generation, or if it’s related to
> GNOME/Mutter (*mutter-common* 48~beta-3) or Firefox or the Web video player
> used by the site.
>
> As often the case with this, I have no way to reliably reproduce it, and in
> this case to reproduce the warning. I can only say, that this warning has
> not been logged in the available log files since September 2024. Linux
> “6.11-rc0” was used then. Please find the log messages attached.
>
> In case this information is not useful, should this happen again, it’d be
> great if you could suggest what and how I should collect debugging
> information next time.
Assuming no explicit usage of SCHED_DEADLINE, I would say the warning
message might be related to the recently introduced deadline servers:
5f6bd380c7bd ("sched/rt: Remove default bandwidth control") and related
commits.
They were merged in v6.12 (IIRC), though, so I would expect you had
noticed already before if they introduced issues on your setup? That
said, it might also be the case that something else changed more
recently that now triggers a corner case.
The warning message per-se it's not fatal, it just warns that the kernel
is recovering from an unexpected situation. Did you notice that things
went back to normal (no lag from a user perspective) right after that
message was printed?
Thanks,
Juri
next prev parent reply other threads:[~2025-02-20 13:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 10:47 Paul Menzel
2025-02-20 13:35 ` Juri Lelli [this message]
2025-02-20 20:18 ` Paul Menzel
2025-02-21 22:13 ` Paul Menzel
2025-02-24 9:50 ` Juri Lelli
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=Z7cvifR-y0CWK1e6@jlelli-thinkpadt14gen4.remote.csb \
--to=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pmenzel@molgen.mpg.de \
--cc=vincent.guittot@linaro.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
all inboxes | Powered by JetHome®