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

[Stian Halseth]

Hi Frederic,

On Wed, 2026-10-28 at 15:14 +0100, Frederic Weisbecker wrote:
> 
> So let me depict that:
> 
> // clocksource = jiffies ?
> // clockevent = lapic ?
> tick_setup_device()
>    tick_next_period = ktime_get() // jiffies_to_nsecs(jiffies)
> 
> tick_periodic()
>    tick_next_period += TICK_NSECS
>    jiffies++ // ktime_get() == tick_next_period
> 
> // jiffies > tsc_early
> clocksource_select()
> 
> tick_periodic()
>    //one tick has passed, so ktime_get() == jiffies + 1

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.

>    tick_next_period += TICK_NSECS
>    jiffies++ // ktime_get() == tick_next_period == jiffies

So after this, tick_next_period == ktime_get() + d.

The same thing as a diagram:

// jiffies -> tsc-early, d after the last tick
clocksource_select()
   ktime_get() == last tick          // the d is not in there

tick_periodic()                      // TICK_NSEC after the last tick
   ktime_get() == last tick + TICK_NSEC - d
   tick_next_period += TICK_NSEC     // == last tick + TICK_NSEC
   // tick_next_period == ktime_get() + d

From a measurement I did with a QEMU guest: at the switch both were
329532326. At the next tick ktime_get() was 331212239, 1.68 ms later,
so d was 2.32 ms, and tick_next_period became 333532326, 2.32 ms
ahead.

/Stian

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