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

[Stian Halseth <stian@itx.no>]

[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]

Hi Frederic,

On Tue, 2026-10-27 at 18:06 +0100, Frederic Weisbecker wrote:

> Ok let me try to picture this:
> 
> Initially, jiffies or tsc-early, not sure, is the clocksource:
> 
> - tick_setup_device() sets tick_next_period to ktime_get()
> - tick_periodic() adds TICK_NSEC to tick_next_period right before updating 
> jiffies. So as you said tick_next_period == ktime_get()
> - Note last_tick is not involved in that mode
> 
> Then later on boot comes a oneshot device:

The clocksource is initially jiffies, and I believe there is a step missing
before the oneshot switch: the clocksource switch, while the tick is still
periodic.

Please let me know where I lose you, or if/when you disagree with
my analysis. Not sure if you're more confused about my attempt of an
explanation, or by what's really happening ;)

Here we go... 

The oneshot switch can only happen inside a tick, so at the earliest
in the first tick after the clocksource switch. In the guest it came 
0.7s later since tsc-early waits for the watchdog in the guest.

So...for a while tick_periodic() runs on tsc-early. ktime now moves
between ticks too, but the next tick still adds a full TICK_NSEC, so
tick_next_period gets ahead of ktime_get() by the part of the period
that had passed at the switch. Still here? :)

In the guest that was measured at 2.3ms. With a periodic lapic it
stays that way, with the TSC deadline timer the following tick is
programmed from ktime again so it is gone, but in Paul's case the
oneshot switch happens in that first tick after the clocksource
switch, so it is still there.

Then finally tick_init_jiffy_update() aligns it upwards. It is not
tick aligned to start with since ktime starts at the sched_clock boot
offset, so that can add most of another tick, and that becomes the
first expiry of the sched timer.

hrtimer_forward_now() doesn't touch it since it is already in the
future. In the guest it ended up 4.66 ms after now at HZ=250, and
tick_do_update_jiffies64() returns early until now gets there.

> 
> last_tick actually gets its first value when the tick is stopped for the
> first time in tick_nohz_stop_tick() and is set to the next tick that won't
> happen.

Yes, that expiry. A stop in the first 0.66 ms saves it as last_tick,
and kcpustat_dyntick_stop() then has last_tick - TICK_NSEC still in
the future. I never caught the stop itself in the guest, but Paul's
registers show now 235623102 and tick_start 236000000.



/Stian

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]