Re: [PATCH v4 2/4] pps: Drop the !NO_HZ_COMMON dependency from NTP_PPS

[David Woodhouse]

On Tue, 2026-09-29 at 08:33 +0200, Rodolfo Giometti wrote:
> On Mon, 2026-09-28 at 20:28 +0100, David Woodhouse wrote:
> > Yeah, working on that now. My first soak test on the nohz_full build
> > didn't have nohz_idle, so it wasn't really very tickless.
> [...]
> > More data, and pretty graphs, when I'm confident of the results and have the
> > A/B testing.
> 
> Thanks, looking forward to it.

It took some side quests to make the thing actually quiesce for 5
seconds at a time. Runtime PM waking the CPU twice a second just to
decide whether it should put some device to sleep is ironic, Ethernet
stuff with *two* timers when I hadn't even brought it up (and crashing
when I unbind it!), and some other stuff around the 1 second period.

And of course the "PPS" actually being "PPfiveS".

Two things I learned from the overnight run:

When second_overflow() is delivering skew, timekeeping_max_deferment()
should trigger a wakeup at the end of the second to ensure that the
skew gets recalculated — rather than leaving it active indefinitely.
That's true even without hardpps, but with STA_PPSTIME causing
ntp_offset_chunk() to deliver the *entire* phase offset each second, it
gets more important.

My overnight results were perturbed by a patch I'd intended to drop
from my tree (deliberately skewing to eliminate ntp_error, which has
exactly the same problem as above). Although the same fix addresses
both, and I *am* seeing residue left in ntp_error from the way that
hardpps overwrites the time_offset even while it's being skewed in the
opposite direction, so I'm restarting the run with that corrected.

So the results at https://david.woodhou.se/ntptest-r64/tickless/ need
to be redone, but you can take a look and shout if you want me to
change what I'm capturing or how I'm doing it.

The test case is
https://david.woodhou.se/ntptest-r64//initramfs/src/init.c

It first sets the clock roughly from NMEA and then lets the kernel
hardpps discipline loose on it to do the whole of the frequency
correction from the nominal crystal frequency, and the phase error from
NMEA. (I did have it handling a few pulses in userspace and priming the
frequency and phase, to skip to the steady state. But that's cheating.)

Attachment: smime.p7s
Description: S/MIME cryptographic signature