Re: Why was the timehands_count sysctl added?

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.