From nobody Fri Jun 03 08:28:38 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 973F21B66DA7 for ; Fri, 3 Jun 2022 08:28:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDwyP57cjz3Bs6 for ; Fri, 3 Jun 2022 08:28:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id CD5E389298; Fri, 3 Jun 2022 08:28:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2538ScMi080177 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jun 2022 08:28:38 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2538ScDg080165; Fri, 3 Jun 2022 08:28:38 GMT (envelope-from phk) Message-Id: <202206030828.2538ScDg080165@critter.freebsd.dk> To: Sebastian Huber cc: Konstantin Belousov , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() In-reply-to: From: "Poul-Henning Kamp" References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80163.1654244918.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 03 Jun 2022 08:28:38 +0000 X-Rspamd-Queue-Id: 4LDwyP57cjz3Bs6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MLMMJ_DEST(0.00)[hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N -------- 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= .