Re: [PATCH] clocksource: Require consecutive frequency skew samples before demotion

[Thomas Gleixner]

On Tue, Sep 08 2026 at 19:10, Chaohai Chen wrote:
> The clocksource watchdog marks a clocksource unstable as soon as a single
> frequency comparison against the watchdog clocksource exceeds the allowed
> skew:
>
> 	if (abs(wd_delta - cs_delta) < (max_delta >> ppm_shift) + wd_seq)
> 		return true;
> 	watchdog_data.result = WD_FREQ_SKEWED;
>
> While the readout window is already protected against transient
> disturbances (SMIs, NMIs, long IRQs, vCPU preemption) via the
> WATCHDOG_READOUT_MAX_NS check and WATCHDOG_FREQ_RETRIES, the frequency
> skew decision itself has no hysteresis: a single outlier sample is enough
> to demote the clocksource. This demotion is irreversible at runtime -
> the rating is cleared to 0, CLOCK_SOURCE_VALID_FOR_HRES is dropped, and on
> x86 the one-shot tsc_unstable latch prevents any recovery.
>
> A single skew sample can be produced by a transient glitch of the
> watchdog clocksource itself (HPET/PMTMR are not immune to hiccups or
> errata) rather than by an actual defect of the watched clocksource.

Which systems expose such issues in the real world?

> The threshold defaults to 3 and is tunable via the
> clocksource.wd_freq_skew_confirm module parameter (also usable on the
> kernel command line and writable at runtime through
> /sys/module/clocksource/parameters/wd_freq_skew_confirm), clamped to

No. We just got rid of all related knobs and we are not adding new ones
which are never used and not understandable at all.

Thanks,

        tglx