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

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

[Stian Halseth]

kcpustat_dyntick_stop() warns if idle ends before the tick period
that the next tick will account has started. That happens on x86 in
a CPU's first idle period with the tick stopped, right after the
switch from the jiffies clocksource to tsc-early.

On the jiffies clocksource ktime only moves at the tick. When the
clocksource switches some time d after a tick, that d is lost: ktime
continues from the value of the last tick. The next tick comes
TICK_NSEC after the last one, but ktime has only moved TICK_NSEC - d,
while tick_periodic() still adds a full TICK_NSEC to tick_next_period,
which is now d ahead of ktime. When NOHZ starts,
tick_init_jiffy_update() rounds it up to a multiple of TICK_NSEC and
the sched timer is armed there, up to nearly two ticks after now. A
tick stop saves that as ts->last_tick, and an idle exit before now
reaches ts->last_tick - TICK_NSEC sees the tick period in the future.

Nothing is accounted twice then. The first tick covers a period that
starts after the idle exit, and the code already handles it. Drop the
warning.

Fixes: 96a494c9cfd8 ("sched/cputime: Don't account idle time twice after dyntick-idle")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/all/bfe9b14a-6e65-41c5-b638-26f6e033788b@molgen.mpg.de/
Reported-by: Breno Leitao <leitao@debian.org>
Link: https://lore.kernel.org/all/auTCQauaU733PY5z@gmail.com/
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/all/CAHk-=winC2u2D1FAX5grfq9F=bxmARxhuiQ4MvHAiJFu3iF6gw@mail.gmail.com/
Signed-off-by: Stian Halseth <stian@itx.no>
---
v2: rewrite the commit message, which named the wrong variable and
had the wrong clocksource. The code is unchanged from v1. Add the
reports from Breno and Linus.
v1: https://lore.kernel.org/all/20261025100202.2584654-1-stian@itx.no/

 kernel/sched/cputime.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 9e0fb8633d823..17f3cbd5d403a 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -478,7 +478,12 @@ void kcpustat_dyntick_stop(u64 now, u64 tick_start)
 			kc->idle_tick_overlap = 0;
 		}
 		tick_start = max(tick_start, kc->idle_dyntick_entry);
-		if (!WARN_ON_ONCE(now < tick_start))
+		/*
+		 * After a switch from the jiffies clocksource the tick can be
+		 * armed more than a tick ahead, so the period may not have
+		 * started yet.
+		 */
+		if (now > tick_start)
 			kc->idle_tick_overlap += now - tick_start;
 		kcpustat_idle_stop(kc, now);
 		kc->idle_dyntick = false;
-- 
2.43.0

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

[Kayra Cizmeci]

On Sat, Oct 31, 2026 at 09:14:07AM +0100, Stian Halseth wrote:
>  kernel/sched/cputime.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 9e0fb8633d823..17f3cbd5d403a 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -478,7 +478,12 @@ void kcpustat_dyntick_stop(u64 now, u64 tick_start)
>  			kc->idle_tick_overlap = 0;
>  		}
>  		tick_start = max(tick_start, kc->idle_dyntick_entry);
> -		if (!WARN_ON_ONCE(now < tick_start))
> +		/*
> +		 * After a switch from the jiffies clocksource the tick can be
> +		 * armed more than a tick ahead, so the period may not have
> +		 * started yet.
> +		 */
> +		if (now > tick_start)
>  			kc->idle_tick_overlap += now - tick_start;
>  		kcpustat_idle_stop(kc, now);
>  		kc->idle_dyntick = false;
> -- 
> 2.43.0


TICK_NSEC = 4

         switch
            |
            v
Real: 8 9 10 11 12 13 14 15 16 17 18

Time: 8 8 8  9  10 11 12 13 14 15 16

Tick: 8 8 8  8  10 10 10 10 10 10 16


So if we enter idle at real-12, and exit at real-13 this happens:

last_tick is 16, so last_tick - 4 = 12. But normally, last_tick needs to
be 14 and tick_start needs to be 10. Or am I missing something?

IDK if there is a better solution tho.
Maybe fixing it from the root would be better. If its even possible to do it
cleanly...


But this code works correct.

Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>



Thanks,

Kayra

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

[Stian Halseth]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

Hi Kayra,

On Sat, 2026-10-31 at 14:47 +0300, Kayra Cizmeci wrote:
> 
> TICK_NSEC = 4
> 
>          switch
>             |
>             v
> Real: 8 9 10 11 12 13 14 15 16 17 18
> 
> Time: 8 8 8  9  10 11 12 13 14 15 16
> 
> Tick: 8 8 8  8  10 10 10 10 10 10 16
> 
> 
> So if we enter idle at real-12, and exit at real-13 this happens:
> 
> last_tick is 16, so last_tick - 4 = 12. But normally, last_tick needs to
> be 14 and tick_start needs to be 10. Or am I missing something?

Your diagram is correct AFAICT, and that's the case this patch is about.

10 and 14 would follow the old periodic ticks, but after the switch the
tick runs on a grid that is d ahead of them.

Idle ends at 11, before tick_start at 12. The code already accounted
that correctly but warned about it, and v2 drops the warning.

> 
> IDK if there is a better solution tho.
> Maybe fixing it from the root would be better. If its even possible to do it
> cleanly...

Someone might have a better idea, but maybe we could realign
tick_next_period when the clocksource switches away from jiffies.

I kept v2 to the warning though, since this is a regression in the
current release, and a change to the tick setup could be a potential
follow-up.

Thanks for the review!

/Stian


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]