linux-kernel - Re: Linux warns `sched: DL replenish lagged too much`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47903c9d-3949-43b3-8f27-d59db20acb1e@molgen.mpg.de>
Date: Thu, 20 Feb 2025 21:18:48 +0100
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: Linux warns `sched: DL replenish lagged too much`

Dear Juri,


Thank you for your quick reply.

Am 20.02.25 um 14:35 schrieb Juri Lelli:

> On 20/02/25 11:47, Paul Menzel wrote:

>> 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,

Indeed, it first appeared in v6.12-rc1.

> 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.

On this device, I sometimes experience lags after resuming from ACPI S3, 
and, although I cannot prove it, using USB-C mini docks (LMP USB-C mini 
Dock [1] or Dell DA300) seems to increase the chances of hitting the 
problem. Re-plugging and doing ACPI S3 suspend/resume again often helps.

> 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?

As far as I remember, the lagging stayed even after the log was printed. 
In this case, I had to reboot the device, and until now – with no ACPI 
S3 suspend/resume – it works fine.


Kind regards,

Paul


[1]: https://lmp-adapter.com/product/lmp-usb-c-mini-dock/