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

[Stian Halseth]

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?

> 
> 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(). 

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.

/Stian

Attachment: signature.asc
Description: This is a digitally signed message part