Re: [PATCH v2] sched/cputime: Don't account idle time twice after dyntick-idle

[Frederic Weisbecker <frederic@kernel.org>]

Le Mon, Oct 05, 2026 at 09:40:10PM +0200, Stian Halseth a écrit :
> On idle exit the dyntick-idle accounting accounts the time up to now,
> then the tick is restarted on its old period. The first tick accounts a
> whole TICK_NSEC to whatever runs, although the part of that period
> before the idle exit has just been accounted as idle time, or with
> IRQ_TIME_ACCOUNTING as IRQ time. That is up to a full tick per idle
> exit, and /proc/stat reports more idle time than wall time.
> 
> Record how much of the current tick period dyntick-idle has accounted,
> and leave it out of the tick that ends the period.
> 
> Fixes: cf6444c3e1bb7 ("tick/sched: Unify idle cputime accounting")
> Link: https://lore.kernel.org/all/20261004142724.3896396-1-stian@itx.no/
> Signed-off-by: Stian Halseth <stian@itx.no>
> ---
> v2:
> - Keep the overlap per tick period, so that a second dyntick-idle
>   period before the tick adds to it instead of replacing it (Frederic)
> - Read it through a helper in the NO_HZ_COMMON block, with a stub in
>   its #else, like kcpustat_field_dyntick(). IS_ENABLED() does not build,
>   as the field only exists with NO_HZ_COMMON. The helper is static
>   inline, as there is no user with VIRT_CPU_ACCOUNTING_NATIVE.
> 
> Frederic's case does not happen in my tests on its own. Since
> f4c31b07b136 ("sched: idle: Consolidate the handling of two special
> cases"), without a cpuidle driver or with a single state, the tick is
> only stopped after it woke up the idle loop, and that tick takes the
> overlap first. With a test-only change that stops the tick on every
> idle entry, as a governor may, the guest added to a pending overlap
> about 900 times a second under a pipe ping-pong between two CPUs.
> 
> So it is not what is left with steal time. That is the same with v2,
> +0.7% to +1.4%, and only shows when the task also spins for 1 ms after
> each wakeup.
> 
> Total CPU time per wall second on the loaded CPU, v2:
> 
>   SPARC T7-1, HZ=100, busiest CPU*       1.0001
>   SPARC T7-1, HZ=100, 3.7 ms sleeps      1.0000
>   SPARC T7-1, HZ=100, 25 ms sleeps       0.9998
>   SPARC T7-1, HZ=100, pipe ping-pong     1.0000
>   x86_64 KVM guest, HZ=250, 3.7 ms       0.997  (1.505 before)
>   same guest, pipe ping-pong             1.000  (1.152 before)
>   same guest, 9 ms sleeps                0.985
> 
>   * under its normal load, about 90 tick stops/s
> 
> The guest was tested as for v1, with and without IRQ_TIME_ACCOUNTING,
> with highres=off, with steal time and with the forced restart path. The
> -1.5% with 9 ms sleeps is the late tick delivery described in v1.

IIUC, there is still an excess of cputime accounted here sometimes, right?
And that never happened before the patchset that rewrote the cputime idle
accounting. Am I understanding correctly?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs