Am 18.09.2026 um 17:54 schrieb Sasha Levin:
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")
Ah ok, that third one I missed, so it didn't work out for me.
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.
Sounds complicated; no wonder I was unable to figure this out on my own.
Beste Grüße, Peter Schneider