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

On Wed, Apr 15, 2026 at 09:10:53PM +0000, John Stultz wrote:
> From: Peter Zijlstra <[email protected]>
>
> [ Upstream commit 101f3498b4bdfef97152a444847948de1543f692 ]
>
[...]
> (cherry picked from commit 101f3498b4bdfef97152a444847948de1543f692)
> [jstultz: Resolved minor collision in the revert against 6.18-stable]
> Signed-off-by: John Stultz <[email protected]>

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) <[email protected]>

[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/stable/PAWPR07MB100712177EB29A65F4385E4C29ACF2@PAWPR07MB10071.eurprd07.prod.outlook.com/
[3] https://lore.kernel.org/stable/[email protected]/