Re: widening ticks

On Sun, Jan 12, 2025 at 11:16:51AM +0900, Tomoaki AOKI wrote:
> Replying to ML only, as Mark's gmail address seems to block previous
> one.
> 
> On Sat, 11 Jan 2025 18:00:12 -0500
> Mark Johnston <markj@freebsd.org> wrote:
> 
> > On Sun, Jan 12, 2025 at 07:50:38AM +0900, Tomoaki AOKI wrote:
> > > On Sat, 11 Jan 2025 17:35:36 -0500
> > > Mark Johnston <markj@freebsd.org> wrote:
> > > 
> > > > On Sun, Jan 12, 2025 at 04:35:43AM +0900, Tomoaki AOKI wrote:
> > > > > Not an example of code, but for example, when ticksl is at
> > > > > 0x7fffffffffffffff (positive value), ticks shoule be 0xffffffff
> > > > > (negative value), if I read the diff correctly.
> > > > > The same thing starts happening ticksl is at 0x0000000080000000 throug
> > > > > 0x00000000ffffffff and values alike. So signs (carry bits, usually the
> > > > > leftmost bit of each) should be checked separately for ticksl and ticks.
> > > > 
> > > > That's true, but I can't see why any code would care about this?
> > > 
> > > While ticks is defined as (signed) int, it shoule be turnaround when it
> > > reaches at 0x7fffffff (as incrementing it causes overflow).
> > > Is ticks allowed to be minus value? My guess is that it is monotonic
> > > counter.
> > 
> > Yes, INT_MAX ticks elapse in approximately 25 days at 1000Hz.  In fact,
> > ticks is initialized to INT_MAX - <small number> in subr_param.c so that
> > it wraps around shortly after boot, after which it is negative.
> > 
> > Kernel code should not care about the sign of ticks.
> 
> Thanks! I've overlooked it.
> 
> BTW, does tickl restricted with INT_MAX, too? (In detail, although tickl
> has the type long, but actually the range of the values used are
> restricted with INT_MAX?)

No, that's the point of the change: the kernel now increments a counter
of type long, so it will eventually reach LONG_MAX.  Existing code which
references ticks will still get a 32-bit value that behaves the same as
before.