Re: [PATCH v4 3/4] pps: Always use ktime_get_snapshot_id() for pps_get_ts()

[David Woodhouse]

On Thu, 2026-10-01 at 15:14 +0200, Miroslav Lichvar wrote:
> On Mon, Sep 28, 2026 at 09:58:02AM +0200, Rodolfo Giometti wrote:
> > On Sat, 2026-09-26 at 21:38 +0100, David Woodhouse wrote:
> > > So yes, the specific code path you're looking at *does* get slightly
> > > longer (50ns to the counter read instead of 30ns).
> > [...]
> > > However, they are *entirely* in the noise, as there's about 600 ns of
> > > hardware and 2-4 *microseconds* of software latency before we even get
> > > there.
> > 
> > Thanks for measuring it, and on real hardware with a real edge. That
> > answers my concern: ~20 ns of constant cost against microseconds of
> > latency upstream of the handler is not something PPS can see, and
> > trading it for the removal of a non-constant error is the right
> > trade.
> 
> FWIW, there are some polling versions of the pps-gpio driver (out of
> tree), which provide much more stable measurements by trading
> interrupts for higher CPU use and where this additional delay might be
> visible.

Hm, interesting. Got a reference? What does it do, set a timer for when
it thinks the end of the second is imminent, and spinwait then?

I imagine it's something along the lines of:

	count2 = arch_inlined_clocksource_read();
	do {
		count1 = count2;
		pulse = gpio_read();
		count2 = arch_inlined_clocksource_read();
	} while (!pulse && !too_late());

	/* And *now* we can take as long as we like to convert
	 * avg(count1,count2) into an actual time */

If it *doesn't* have the inlined read as the fast path like that, then
it isn't even *trying*, and one might argue that it doesn't get to have
an opinion on the 20ns I just stole from it. (I *did* give most of that
20ns back, although the arm64 maintainers aren't keen on inlining the
clocksource; if we do really want it, we'd have to make a real-world
case that isn't a microbenchmark.)

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