Re: Why was the timehands_count sysctl added?

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/