Re: pps_capture() and pps_fetch()

--------
Sebastian Huber writes:

> On 02.06.22 06:59, Konstantin Belousov wrote:
> > I am not sure about supposed use of the pps(9) API, but for me it looks
> > like generation rechecks cut potentially CPU-consuming computation in the
> > interrupt handler context.  For instance, pps_event() seems to be used _some_
> > time after pps_capture(), and needs to do a lot.  So there is a chance
> > that the data from pps_capture() is already not relevant due to timecounter
> > advance.
> > 
> > On the other hand, single read of the generation should be quite cheap,
> > the cache line should be hot and we spent it to avoid larger waste.  In
> > other words, doing it probably slighly improves system latency.
> > 
> > Note that I did not wrote the code and speculataion above is a speculation.

I would have to dig out 20 year old notes, which I am not even sure I know where
are, to find the definitive answer.

I think the general thrust of Kontantin's theory above is not wrong,
but am pretty sure that fast timecounter roll-over had a lot to
do with it too.

A 16 bit counter running at 10-20 MHz rolled over ~5 milliseconds.

A lot of stuff have happened since then, modern timecounters last
longer, our scheduling has become much better and the code has been
improved in various ways (Konstantin's use of atomics for instance).

> I just ask because we may want to use this code in a spacecraft and 
> every "if" increases the time to specify and test the implementation.

Weee... CODE in SPAAAAAAAACEEEEEeeeee! :-)

> The expensive part in pps_event() is after the th_generation checks. I 
> think from a performance point of view, the checks can be reduced to 
> just one th_generation check. I am more concerned if this would 
> introduce a subtle functional change.

Assuming that your timecounter hardware does not roll over fast enough
to open any races, I think that is correct.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.