Re: [PATCH v2] sched/cputime: Don't warn when the tick period starts after idle exit

[Kayra Cizmeci]

On Sat, Oct 31, 2026 at 09:14:07AM +0100, Stian Halseth wrote:
>  kernel/sched/cputime.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 9e0fb8633d823..17f3cbd5d403a 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -478,7 +478,12 @@ void kcpustat_dyntick_stop(u64 now, u64 tick_start)
>  			kc->idle_tick_overlap = 0;
>  		}
>  		tick_start = max(tick_start, kc->idle_dyntick_entry);
> -		if (!WARN_ON_ONCE(now < tick_start))
> +		/*
> +		 * After a switch from the jiffies clocksource the tick can be
> +		 * armed more than a tick ahead, so the period may not have
> +		 * started yet.
> +		 */
> +		if (now > tick_start)
>  			kc->idle_tick_overlap += now - tick_start;
>  		kcpustat_idle_stop(kc, now);
>  		kc->idle_dyntick = false;
> -- 
> 2.43.0


TICK_NSEC = 4

         switch
            |
            v
Real: 8 9 10 11 12 13 14 15 16 17 18

Time: 8 8 8  9  10 11 12 13 14 15 16

Tick: 8 8 8  8  10 10 10 10 10 10 16


So if we enter idle at real-12, and exit at real-13 this happens:

last_tick is 16, so last_tick - 4 = 12. But normally, last_tick needs to
be 14 and tick_start needs to be 10. Or am I missing something?

IDK if there is a better solution tho.
Maybe fixing it from the root would be better. If its even possible to do it
cleanly...


But this code works correct.

Reviewed-by: Kayra Cizmeci <kayracizmeci@xxxxxxxxx>



Thanks,

Kayra