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

[Frederic Weisbecker]

Le Mon, Oct 26, 2026 at 06:28:44PM +0100, Stian Halseth a écrit :
> Hi Frederic,
> 
> 
> On Mon, 2026-10-26 at 17:42 +0100, Frederic Weisbecker wrote:
> > 
> > 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?
> 
> No, not going backward, my description was vague, sorry.
> It's tick_next_period that runs ahead, not ktime going back.
> 
> Also, please challenge my assumptions, as I might be analyzing this
> wrong. This codebase is still pretty new to me, and I might
> misinterpret some things.
> 
> But from how I see it, on jiffies, ktime only moves at the tick. So
> seen from the tick's point of view, tick_next_period == ktime_get(). 
> 
> After the switch ktime keeps moving between ticks, but the next tick
> still adds a full TICK_NSEC, so tick_next_period ends up ahead of now
> by the part of the period that jiffies never counted. 
> In a KVM guest at HZ=250 that was 2.3 ms.
> 
> Do you follow my reasoning?


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:

- tick_init_jiffy_update() adjusts tick_next_period to be aligned to TICK_NSEC
- tick_sched_do_timer() -> tick_do_update_jiffies64() sets tick_next_period to
  roughly ktime_get() + TICK_NSEC

> 
> > 
> > Also refine-jiffies is not a suitable clocksource for nohz, so
> > last_tick shouldn't be updated while refine-jiffies is the
> > clocksource.
> 
> Yes, right. last_tick gets its first value from the sched timer expiry,
> which is that tick_next_period rounded up to a tick multiple by
> tick_init_jiffy_update(). 

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.

> 
> In the guest that made the first expiry 4.66 ms after now, so for the
> first 0.66 ms a tick stop leaves last_tick - TICK_NSEC in the future.
> Paul's registers show the same, now 235623102 with last_tick
> 240000000.
> 
> I can rewrite the commit message along these lines, or fix up
> tick_next_period at the switch instead if you prefer that.

I'm still confused by what is actually happening.

Thanks.

> 
> /Stian



-- 
Frederic Weisbecker
SUSE Labs