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

From: Zhan Xusheng <[email protected]>

On Tue, Jul 28, 2026 at 09:30:39 +0100, Christian Loehle wrote:
> Interesting, so your guests (no cpuidle) need the tick stopped at every
> idle entry to not regress, i.e. the below?
> Is there anything obvious that shows why that would be? Maybe in the
> hypervisor behaviour?

I think it lines up with the got_tick heuristic rather than anything
hypervisor-specific in the guest kernel path.

do_idle() resets got_tick to false at the top of every idle episode and
passes it as stop_tick, so the first idle iteration always calls
idle_call_stop_or_retain_tick(false); tick_nohz_idle_enter() hasn't stopped
the tick at that point, so that takes the retain branch. Only after the
tick fires once (got_tick becomes true) does a later iteration stop it.
So with f4c31b the no-driver path leaves the periodic tick armed at the
start of every idle episode, whereas the old code stopped it
unconditionally.

That also explains the test results: forcing (false) keeps the retain and
still regresses, while (true) / the direct tick_nohz_idle_stop_tick()
restores the old always-stop and recovers.

The hypervisor is then where the consequence shows up: a guest that leaves
its tick running keeps a ~1/HZ timer pending, so the host sees an imminent
timer and keeps waking/scheduling the vCPU instead of letting it idle. That
is at least consistent with the shapes - the x86 shape at HZ=1000 regressed
more (-29%) than the arm shape at HZ=250 (-10%), i.e. more retained ticks,
more interference. For the no-driver bare halt there is no governor/state
selection that a retained tick could help, so stopping unconditionally is
strictly better.

Thanks,
Zhan Xusheng