Files
linux/include/linux
David Woodhouse d375af5899 timekeeping: Drive time_offset skew via per-tick ntp_error transfer
Currently, the phase offset of time_offset and time_adjust is delivered
by adjusting tick_length in second_overflow(), and immediately draining
time_offset/time_adjust by the amount that the tick_length adjustment is
*estimated* to cause. This is fairly approximate, in part because it is
not always correct to assume that precisely NTP_INTERVAL_FREQ ticks will
occur between one call to second_overflow() and the next. It could also
over and under-run in the final second of delivery.

Instead of inflating tick_length, transfer the intended skew directly
into ntp_error each tick to achieve the desired rate.

In second_overflow(), calculate skew_delta which is the per-tick slew
rate, in the same units as time_offset: (ns << NTP_SCALE_SHIFT) / HZ.

In logarithmic_accumulation(), drain up to 'skew_delta' time units from
time_offset into ntp_error to drive the overall effective rate. The new
ntp_drain_skew() function returns the amount which is actually 'claimed'
by time_offset (and in a future patch, time_adjust). Any overrun which
is delivered by the changed 'mult' (as described below) but not claimed
by ntp_drain_skew() will remain in ntp_error to be corrected away in
subsequent ticks.

Simply transferring the precise amount from time_offset to ntp_error
would be sufficent to make the time *eventually* converge, however the
skew delivered is limited by the choice of { mult, mult+1 } each tick
and thus the convergence would be extremely slow.

In theory we could inflate ntp_err_mult with the magnitude of ntp_error
in the general case — but that would cause overcorrection in a tickless
kernel. Instead, in timekeeping_adjust(), take skew_delta into account
when calculating 'mult', such that the available {mult, mult+1} choices
bracket the overall effective rate *including* the skew, to avoid the
delta just building up in ntp_error.

The effect is that the inflated 'mult' causes ntp_error to grow because
xtime_interval is (e.g.) longer than the true tick_length. But then the
same delta is removed again as it's drained from time_offset.

This gives behaviour equivalent to the old tick_length += delta approach
but with exact per-tick accounting of the time_offset actually imparted
to the clock, and no overrun.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Assisted-by: Kiro:claude-opus-4.8
Link: https://patch.msgid.link/20260621220051.1030462-5-dwmw2@infradead.org
2026-07-10 09:20:54 +02:00
..
2026-02-11 13:44:47 +01:00
2026-04-02 15:52:49 +02:00
2026-03-18 15:11:40 +05:30
2026-05-21 13:04:42 +02:00
2026-03-19 23:55:27 +01:00
2026-06-17 11:32:14 +01:00
2026-05-28 21:24:54 -07:00
2026-01-20 19:44:19 -08:00
2026-06-16 08:53:53 -07:00
2026-04-03 16:53:50 -04:00
2026-06-07 10:03:01 -07:00
2026-03-02 17:08:05 -05:00
2026-05-28 17:45:46 -07:00
2026-06-05 00:34:55 -04:00
2026-05-18 11:16:29 +02:00
2026-05-19 17:26:07 +02:00
2025-12-13 20:04:32 +12:00
2026-05-28 11:36:59 -04:00
2026-04-07 17:38:07 +02:00
2025-12-23 11:23:10 -08:00
2026-02-27 16:40:16 +01:00
2026-06-05 17:46:17 -07:00
2026-01-12 16:52:09 +01:00
2026-05-28 21:24:43 -07:00
2026-02-06 07:29:14 -07:00
2026-06-10 10:42:55 -04:00
2026-04-05 13:53:28 -07:00
2026-01-05 16:43:31 +01:00
2026-01-11 06:09:11 -10:00
2026-04-01 10:19:41 +02:00
2026-04-03 16:53:50 -04:00
2026-04-03 16:53:50 -04:00
2026-03-18 09:59:57 +00:00
2026-04-06 11:39:54 +02:00
2026-04-05 13:53:00 -07:00
2026-03-17 15:34:47 +05:30
2025-12-29 11:53:38 +01:00
2026-01-26 20:02:27 -08:00
2026-03-08 11:06:53 +01:00
2026-06-26 22:18:34 -04:00
2026-03-27 07:35:05 -07:00
2026-01-30 11:34:34 +00:00
2026-04-05 13:53:10 -07:00
2026-06-23 17:32:06 -05:00
2026-02-10 11:39:31 +01:00
2026-01-11 06:09:11 -10:00
2026-04-20 11:35:17 -07:00
2026-05-26 11:02:01 +02:00
2026-02-27 16:40:16 +01:00
2026-01-11 06:09:11 -10:00
2026-03-08 11:06:53 +01:00
2026-03-31 07:04:00 -06:00
2026-03-25 20:11:29 +01:00
2026-03-13 08:22:54 +01:00
2026-05-11 16:59:43 +02:00
2026-03-12 15:05:34 +01:00
2026-04-06 09:06:39 +02:00
2026-03-30 16:43:24 -06:00
2026-01-30 18:26:59 -08:00
2026-06-06 15:22:44 +02:00