Re: [REGRESSION] sched/idle: Sysbench threads regression after f4c31b07b136

From: Zhan Xusheng <[email protected]>=0D

On Tue, Jul 28, 2026 at 09:30:39 +0100, Christian Loehle wrote:=0D
> Interesting, so your guests (no cpuidle) need the tick stopped at every=0D
> idle entry to not regress, i.e. the below?=0D
> Is there anything obvious that shows why that would be? Maybe in the=0D
> hypervisor behaviour?=0D
=0D
I think it lines up with the got_tick heuristic rather than anything=0D
hypervisor-specific in the guest kernel path.=0D
=0D
do_idle() resets got_tick to false at the top of every idle episode and=0D
passes it as stop_tick, so the first idle iteration always calls=0D
idle_call_stop_or_retain_tick(false); tick_nohz_idle_enter() hasn't stopped=
=0D
the tick at that point, so that takes the retain branch. Only after the=0D
tick fires once (got_tick becomes true) does a later iteration stop it.=0D
So with f4c31b the no-driver path leaves the periodic tick armed at the=0D
start of every idle episode, whereas the old code stopped it=0D
unconditionally.=0D
=0D
That also explains the test results: forcing (false) keeps the retain and=0D
still regresses, while (true) / the direct tick_nohz_idle_stop_tick()=0D
restores the old always-stop and recovers.=0D
=0D
The hypervisor is then where the consequence shows up: a guest that leaves=
=0D
its tick running keeps a ~1/HZ timer pending, so the host sees an imminent=
=0D
timer and keeps waking/scheduling the vCPU instead of letting it idle. That=
=0D
is at least consistent with the shapes - the x86 shape at HZ=3D1000 regress=
ed=0D
more (-29%) than the arm shape at HZ=3D250 (-10%), i.e. more retained ticks=
,=0D
more interference. For the no-driver bare halt there is no governor/state=0D
selection that a retained tick could help, so stopping unconditionally is=0D
strictly better.=0D
=0D
Thanks,=0D
Zhan Xusheng=0D