Re: [PATCH 6.18] sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag")
Peter Zijlstra <[email protected]>
| Newsgroups | org.kernel.vger.stable,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 <[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]/ Yeah, this should be fine without 4823725d9d1d.