Re: [PATCH v2 1/7] sched/fair: Fix zero_vruntime tracking

From: Peter Zijlstra

Date: Mon Feb 23 2026 - 09:18:21 EST


On Mon, Feb 23, 2026 at 02:09:52PM +0100, Dietmar Eggemann wrote:
> On 19.02.26 08:58, Peter Zijlstra wrote:
> > 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.
>
> Tried hard but I don't get the last clause.

When prev==next, then put_prev_set_next_task() bails out and we'll never
hit __enqueue_entity()/__dequeue_entity().

> [...]
>
> > While there, optimize avg_vruntime() by noting that the average of one value is
> > rather trivial to compute.
> >
>
> nitpick:
>
> > 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 "^>"
> ^
> |
> Works
> only w/o this comma for me.

Hmm, weird, for me:

cat /sys/kernel/debug/sched/debug | grep ^cpu#2
cpu#2, 2500.000 MHz
cpu#20, 2500.000 MHz
cpu#21, 2500.000 MHz
cpu#22, 2500.000 MHz
cpu#23, 2500.000 MHz
cpu#24, 2500.000 MHz
cpu#25, 2500.000 MHz
cpu#26, 2500.000 MHz
cpu#27, 2500.000 MHz
cpu#28, 2500.000 MHz
cpu#29, 2500.000 MHz

And that ',' was added because otherwise it would match the full 20
range of CPUs too, which was not intended ;-)