Re: [PATCH 6.18] sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag")

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Aug 10, 2026 at 01:44:25AM +0000, Jose Fernandez wrote:
> On Wed, Apr 15, 2026 at 09:10:53PM +0000, John Stultz wrote:
> > From: Peter Zijlstra <peterz@infradead.org>
> >
> > [ Upstream commit 101f3498b4bdfef97152a444847948de1543f692 ]
> >
> [...]
> > (cherry picked from commit 101f3498b4bdfef97152a444847948de1543f692)
> > [jstultz: Resolved minor collision in the revert against 6.18-stable]
> > Signed-off-by: John Stultz <jstultz@google.com>
> 
> We have been hitting this on 6.18.y in production. The setup is a
> thread spinning on one CPU inside a cgroup that holds nearly all the
> weight on that CPU. That cgroup's weight gets recalculated on almost
> every tick, and the per-cpu kworker on the same CPU ends up runnable
> but never picked for minutes to hours. We see it as workqueue lockup
> reports and hung tasks stuck behind lru_add_drain_all().
> 
> I tested this patch on 6.18.44 in a 4 vCPU KVM guest with a reproducer
> along the lines of William's script. Three spinners are pinned to three
> CPUs inside a nested cgroup with a high cpu.weight, and some extra load
> in the group keeps its weight changing. On plain 6.18.44 the kworkers
> on those CPUs get stuck runnable but never picked, and their vruntime
> stops moving. With this patch they run normally. Running the same load
> with no cgroup does not starve anything on either kernel.
> 
> Peter said in April that this could go to 6.18 [1]. Janne Huttunen
> posted the same backport last month [2] and Sasha is holding it for
> Peter's ack on taking the revert without 4823725d9d1d [3]. This patch
> and [2] differ only in div64_long() against div_s64().
> 
> Tested-by: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev>
> 
> [1] https://lore.kernel.org/all/20260407134519.GH3738010@noisy.programming.kicks-ass.net/
> [2] https://lore.kernel.org/stable/PAWPR07MB100712177EB29A65F4385E4C29ACF2@PAWPR07MB10071.eurprd07.prod.outlook.com/
> [3] https://lore.kernel.org/stable/20260725192000.stable-0001@kernel.org/

Yeah, this should be fine without 4823725d9d1d.