Re: Why was the timehands_count sysctl added?

From: Ian Lepore <ian_at_freebsd.org>
Date: Sun, 10 Oct 2021 17:44:46 UTC
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.

-- Ian