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

[Zhan Xusheng <zhanxusheng1024@gmail.com>]

Hi Qiao,

On Mon, Oct 26, 2026 at 02:53:25PM +0800, Zhang Qiao wrote:
> 1. Are there hardware or architecture specifications (e.g., ARM64 architected
> timers, RISC-V) requiring counters on all CPUs—including those on different
> dies/sockets—to be perfectly synchronized? If skew is permitted, is there a
> specified maximum allowed skew?

RISC-V's Zicntr extension requires the real-time clocks of all harts to
be synchronized to within one tick.

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.

> 2. If the sequence above is theoretically possible, does generic sched_clock()
> already have a mechanism to handle a counter read that lags behind the shared
> epoch_cyc?

No.  __sched_clock() masks the difference and converts it directly.
Timekeeping's clocksource_delta() returns 0 when the masked delta exceeds
max_delta, but sched_clock has no such check, so a read behind epoch_cyc
gives a delta of nearly a full period and cyc * mult overflows.

Thanks,
Zhan Xusheng