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

[Frederic Weisbecker <frederic@kernel.org>]

Le Sun, Oct 25, 2026 at 11:02:02AM +0100, Stian Halseth a écrit :
> kcpustat_dyntick_stop() warns if idle ends before the current tick
> period has started. It fired once during boot on a Dell XPS 13, in
> CPU 0's first idle period, right after the switch from refined-jiffies
> to tsc-early.
> 
> That can happen. The clocksource switch continues ktime from the last
> jiffies update, so ktime falls behind the tick by up to a tick, and the
> sched timer that NOHZ arms next on tick_next_period can expire more
> than a tick after now. In a KVM guest it was 1.5 ticks ahead after a
> switch from jiffies to hpet. An idle period that stops the tick and
> exits before it fires then sees ts->last_tick - TICK_NSEC after now.

I'm a bit confused by the scenario that happens here. Do you mean that
after switching from a clocksource to another, ktime_get() goes backward?

Also refine-jiffies is not a suitable clocksource for nohz, so last_tick
shouldn't be updated while refine-jiffies is the clocksource.

What am I missing?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs