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

[Stian Halseth]

Hi Frederic,


On Sat, 2026-10-31 at 14:54 +0100, Frederic Weisbecker wrote:
> > 
> > Here is where it goes wrong. One tick has passed in real time, but not
> > in ktime. The switch happened d after the last tick, jiffies never
> > counted that d, and the tsc only counts from the switch on, so here
> > ktime_get() == jiffies + TICK_NSEC - d.
> 
> So that assume that during the clocksource switch, the new clock synchronize
> with the old one so that ktime_get() from the new clock should start from
> the last value of the old clock. I'm having troubles to verify if
> tk_setup_internals() does exactly that. 

Not that one, the timekeeping_forward_now() just before it. It folds
the old clock into xtime_nsec, and tk_setup_internals() keeps that and
only resets cycle_last from the new clock. On jiffies that value is the
last tick.

> 
> [    1.549194] old= 1352575566
> [    1.549930] new= 1352578748
> [    1.550636] clocksource: Switched to clocksource tsc-early
> 
> That's 3 us, it could be the simple difference between the 2 printk.

Look at the timestamps: 736 us passed between the two printks, but
ktime moved 3 us. The 3 us is tsc-early, from the read in
tk_setup_internals() to your second ktime_get(). The time from the
last tick to the first printk, plus the 733 us from there to
tk_setup_internals(), is never counted. That is the d. If you print
ktime_get() in tick_periodic() as well, old= will match the previous
tick exactly.

> 
> But the switch from tsc-early to tsc is much more:
> 
> [    2.639818] old= 2445754540
> [    2.640172] new= 2446107950
> [    2.640927] clocksource: Switched to clocksource tsc
> 
> That's 353 us.

Here the printks are 354 us apart and ktime moved 353 us. Both clocks
run, so nothing is lost: tsc-early counts up to the switch and tsc
continues from there.


/Stian

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