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

[Frederic Weisbecker <frederic@kernel.org>]

Le Wed, Oct 28, 2026 at 06:37:22PM +0100, Stian Halseth a écrit :
> 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.

Ok now that makes sense.

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

I see now.

Thanks

-- 
Frederic Weisbecker
SUSE Labs