Re: [PATCH 0/4] sched: Various reweight_entity() fixes

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Feb 10, 2026 at 09:52:29PM +0100, Vincent Guittot wrote:

> > Subject: sched/fair: Fix zero_vruntime tracking
> > From: Peter Zijlstra <peterz@infradead.org>
> > Date: Mon Feb  9 15:28:16 CET 2026
> >
> > It turns out that zero_vruntime tracking is broken when there is but a single
> > task running. Current update paths are through __{en,de}queue_entity(), and
> > when there is but a single task, pick_next_task() will always return that one
> > task, and put_prev_set_next_task() will end up in neither function.
> >
> > This can cause entity_key() to grow indefinitely large and cause overflows,
> > leading to much pain and suffering.
> >
> > Furtermore, doing update_zero_vruntime() from __{de,en}queue_entity(), which
> > are called from {set_next,put_prev}_entity() has problems because:
> >
> >  - set_next_entity() calls __dequeue_entity() before it does cfs_rq->curr = se.
> >    This means the avg_vruntime() will see the removal but not current, missing
> >    the entity for accounting.
> >
> >  - put_prev_entity() calls __enqueue_entity() before it does cfs_rq->curr =
> >    NULL. This means the avg_vruntime() will see the addition *and* current,
> >    leading to double accounting.
> >
> > Both cases are incorrect.
> >
> > Noting that avg_vruntime is already called on each {en,de}queue, remove the
> > explicit avg_vruntime() calls (which removes an extra 64bit division for each
> > {en,de}queue) and have avg_vruntime() update zero_vruntime itself.
> >
> > Additionally, have the tick call avg_vruntime() -- discarding the result, but
> > for the side-effect of updating zero_vruntime.
> >
> > While there, optimize avg_vruntime() by noting that the average of one value is
> > rather trivial to compute.
> >
> > Test case:
> >   # taskset -c -p 1 $$
> >   # taskset -c 2 bash -c 'while :; do :; done&'
> >   # cat /sys/kernel/debug/sched/debug  | awk '/^cpu#/ {P=0} /^cpu#2,/ {P=1} {if (P) print $0}' | grep -e zero_vruntime -e "^>"
> >
> > PRE:
> >     .zero_vruntime                 : 31316.407903
> >   >R            bash   487     50787.345112   E       50789.145972           2.800000     50780.298364        16     120         0.000000         0.000000         0.000000        /
> >     .zero_vruntime                 : 382548.253179
> >   >R            bash   487    427275.204288   E      427276.003584           2.800000    427268.157540        23     120         0.000000         0.000000         0.000000        /
> >
> > POST:
> >     .zero_vruntime                 : 17259.709467
> >   >R            bash   526     17259.709467   E       17262.509467           2.800000     16915.031624         9     120         0.000000         0.000000         0.000000        /
> >     .zero_vruntime                 : 18702.723356
> >   >R            bash   526     18702.723356   E       18705.523356           2.800000     18358.045513         9     120         0.000000         0.000000         0.000000        /
> >
> > Fixes: 79f3f9bedd14 ("sched/eevdf: Fix min_vruntime vs avg_vruntime")
> > Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> 
> Hi Peter,
> 
> This patch w/ the patchset on top of tip/sched/core create regressions
> for hackbench (tbench doesn't seem to be impacted) on my dragonboard
> rb5

Durr... That was obviously not so expected. Let me go poke.