From: Rik van Riel <riel@surriel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH] sched/fair: clamp rescaled vlag in reweight_entity() to bound entity_key()
Date: Thu, 11 Jun 2026 17:55:26 -0400 [thread overview]
Message-ID: <4d19c305e7df1146948694d66cd44c3a4eee9094.camel@surriel.com> (raw)
In-Reply-To: <20260611081906.GI48970@noisy.programming.kicks-ass.net>
On Thu, 2026-06-11 at 10:19 +0200, Peter Zijlstra wrote:
>
> IOW, the transform totally preserves the limit. If the vlag was bound
> before, it must be bound after.
>
> What am I missing?
You're not missing anything.
After looking at the code, and tracing through things
for much of the afternoon, it turns out the culprit
is the cgroup throttle path.
Specifically, this bug happened on a 6.16 based kernel,
which has the new EEVDF zero_vruntime code, in order
to prevent the EEVDF starvation that could happen with
the old min_vruntime code, but also still has the old
cgroup throttling code.
This leaves a code path where lazy dequeue code combined
with the cgroup throttling code can result in entity_lag
and entity_key reaching ludicrous values, resulting in
the overflow.
This bug reproduces in about 5 minutes on that 6.16 based
kernel, but not with current upstream.
Nothing to do upstream, and it looks like there are a few
changesets upstream that may be able to fix the issue in
the 6.16 based kernel without even needing the clamp from
this patch.
--
All Rights Reversed.
prev parent reply other threads:[~2026-06-11 21:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 14:55 Rik van Riel
2026-06-11 8:19 ` Peter Zijlstra
2026-06-11 21:55 ` Rik van Riel [this message]
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=4d19c305e7df1146948694d66cd44c3a4eee9094.camel@surriel.com \
--to=riel@surriel.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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®