Re: [QUESTION] sched/clock: Potential timestamp jump due to inter-CPU counter skew?

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Oct 26, 2026 at 09:05:00AM +0000, Marc Zyngier wrote:
> On Mon, 26 Oct 2026 08:27:30 +0000,
> Zhan Xusheng <zhanxusheng1024@gmail.com> wrote:
> > 
> > On arm64 the system counter is meant to give all PEs a common view of
> > time, and keeping the copies on separate dies in step is the
> > implementation's job.  The kernel has no tolerance for skew.  The counter
> > errata handled in arm_arch_timer.c (Freescale A-008585, HiSilicon
> > 161010101, Cortex-A73 858921, Allwinner A64) are all reads on a single
> > CPU returning a wrong value, worked around by reading twice; none of them
> > is skew between CPUs.
> 
> Indeed. If the implementation cannot give any two arbitrary CPUs
> anywhere in the system the exact same view of the counter, then this
> implementation is broken, and unsupported. No discussion.

The limit is the cross-cpu latency.

CPU-0			CPU-1

			A = clock();
t1 = A;
t2 = clock();

BUG_ON(t2-t1 < 0);


CPUs must never be able to tell time goes backwards. This is not to say
the clocks must be in perfect sync, only up to the point where the error
is smaller than the observation limit.

So effectively, if software can tell the clock is wobbly, you've lost.