Re: [PATCH 6.12 0000/1102] 6.12.111-rc1 review

[Sasha Levin <sashal@kernel.org>]

On Fri, Sep 18, 2026 at 07:49:48AM +0200, Peter Schneider wrote:
> So I have bisected this warning, and the first bad commit is
> 
> [af5775004c9c02f37be06d2035a056b6abb1cb6c] sched/fair: Fix EEVDF entity
> placement bug causing scheduling lag

Thank you - a second bisect on top of a reverted tree is real work, and
it was the right call. Dropped from the 6.12 queue:

  6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing
                 scheduling lag")

> Trying to revert this from 6.12.111-rc1 however resulted in some
> conflicts I was unable to resolve. There are other dependencies like:

Right, which is why the three patches stacked on top of it came out at
the same time:

  6e3c0a4e1ad1 ("sched/fair: Fix lag clamp")
  51b0e68cfa0a ("sched/eevdf: Fix rb augmented with multi fields")
  9a8bc9bb4c3f ("sched/eevdf: Fix augmented max_slice")

Some background on why this only bites 6.12: the WARN_ON_ONCE(!load) you hit
needs 4423af84b297 ("sched/fair: optimize the PLACE_LAG when se->vlag is zero")
and c70fc32f4443 ("sched/fair: Adhere to place_entity() constraints", which is
a Fixes: for exactly this commit) to be shut up, and 6.12 has neither. More to
the point, upstream has since reverted 6d71a9c61604 outright - 101f3498b4bd
("sched/fair: Revert 6d71a9c61604 ...") from January, which concludes the
original commit "was wrong!" because avg_vruntime() already accounts for
cfs_rq->curr when it is on_rq. 6.12 only ever picked it up as a dependency of
the eevdf fixes above, so carrying placement math that mainline has disowned is
not something we want here.

-- 
Thanks,
Sasha