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

On Wed, Jul 29, 2026 at 4:36 AM Zhan Xusheng <[email protected]> wrote:
>
> 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.

Sure.

That's an intentional modification on the premise that stopping the
tick at the beginning of every idle episode would be more overhead
that letting it run until it actually fires.

> 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.

No, by itself, it doesn't explain anything.  In particular, it doesn't
explain why stopping the tick upfront in every idle episode leads to
better performance.

> 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.

Right, but then why is performance better when the vCPU is put to
sleep at the beginning of every idle episode?

> 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.

What interference do you mean in particular?

It looks like putting an idle vCPU to sleep upfront allows the other
vCPUs to do more work: Is this what you mean?

> For the no-driver bare halt there is no governor/state selection that a retained tick could help, so stopping
> unconditionally is strictly better.

Well, I'm not sure I can agree with this statement just yet.