Re: Why was the timehands_count sysctl added?
- In reply to: Ian Lepore : "Re: Why was the timehands_count sysctl added?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 11 Oct 2021 07:42:56 UTC
On 10/10/2021 19:44, Ian Lepore wrote: > On Sun, 2021-10-10 at 20:39 +0300, Konstantin Belousov wrote: >> On Sun, Oct 10, 2021 at 11:15:39AM -0600, Ian Lepore wrote: >>> On Sat, 2021-10-09 at 14:54 -0600, Warner Losh wrote: >>>> On Sat, Oct 9, 2021, 1:56 PM Konstantin Belousov >>>> <kostikbel@gmail.com> >>>> wrote: >>>> >>>>> On Sat, Oct 09, 2021 at 09:41:28PM +0200, Sebastian Huber >>>>> wrote: >>>>>> Hello, >>>>>> >>>>>> I synchronize currently the port of the FreeBSD timecounters >>>>>> to >>>>>> RTEMS and >>>>>> came across a change in 2019 which I do not understand. Some >>>>>> time >>>>>> ago the >>>>>> timehands were reduced from 10 to two: >>>>>> >>>>>> https://reviews.freebsd.org/D7302 >>>>>> >>>>>> In 2019 this changed again to be up to 16: >>>>>> >>>>>> https://reviews.freebsd.org/D21563 >>>>> This review did not changed it back to 16, the default value is >>>>> still 2. >>>>> It allows to bump the number of used timehands, but normally >>>>> systems run >>>>> with only 2. >>>>> >>>>>> The corresponding sysctl is not documented: >>>>>> >>>>>> https://www.freebsd.org/cgi/man.cgi?query=timecounters&sektion=4 >>>>>> >>>>>> Does someone know why this sysctl to select the count of >>>>>> timehands was >>>>>> added? Is this a performance optimization for some systems? >>>>> To allow for experimentation, and to satisfy some requests >>>>> where >>>>> people >>>>> wanted to have more that 2 timehands. >>>>> >>>> When would someone want that? What's the use case? >>>> >>>> Warner >>>> >>> One known usecase is a single-cpu (non-SMP) system that uses a PPS >>> signal. With only two timehands, a pps pulse that arrives while >>> the >>> system is in an idle-sleep (wait-for-interrupt) state will switch >>> timehands too many times between the wakeup and the capture and >>> trying >>> to use the capture data, so that the th generation count never >>> matches, >>> and in effect you never capture a PPS pulse. I found that on a >>> BeagleBone system. It takes a minimum of 3 timehands for it to >>> work >>> right. >> So should this system automatically adjust the number of timehands? >> There were no similar complaints on UP i386, at least I did not see >> them. >> > I think a required part of the failure scenario was a PPS driver that > used the hardware-capture feature (the hardware latches a counter on > the pps pulse and timecounter->tc_poll_pps() gets called to retrieve > the latched value). i386 hardware doesn't do that. The rareness of > the hardware that works that way (and the additional rareness of people > using that hardware that way) I think was part of why you made it > tunable rather than just increasing the timehands count for everyone, > back when I reported this scenario. Thanks for your insights. So in general the tunable timehands count is an inexpensive knob which may fix issues under some very specific conditions. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/