Date: Fri, 03 Jun 2022 08:28:38 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Sebastian Huber <sebastian.huber@embedded-brains.de> Cc: Konstantin Belousov <kostikbel@gmail.com>, hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() Message-ID: <202206030828.2538ScDg080165@critter.freebsd.dk> In-Reply-To: <c4fe6a08-24b6-522e-3963-cf03eb994496@embedded-brains.de> References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <e1093df0-c719-0421-3e96-c6d7df861a51@embedded-brains.de> <YphDlMyWxDWvJo5Q@kib.kiev.ua> <c4fe6a08-24b6-522e-3963-cf03eb994496@embedded-brains.de>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- 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 look= s > > 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 timeco= unter > > 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. I= n > > other words, doing it probably slighly improves system latency. > > = > > Note that I did not wrote the code and speculataion above is a specula= tion. 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= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202206030828.2538ScDg080165>