Date: Mon, 13 Jan 2025 01:20:39 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: <20250113012039.d476e10859c00f7b55f78280@dec.sakura.ne.jp> In-Reply-To: <Z4PfaXPhyYxSpe1m@nuc> References: <Z37upJ3PineHvA4X@nuc> <Z375yLv59Y1erje9@kib.kiev.ua> <Z38FQ4xphOJTohER@nuc> <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> <Z4KdfhiHOx39Kk2T@nuc> <20250112043543.86b303419f954b2b287d39d1@dec.sakura.ne.jp> <Z4LyOLRlstmMestb@nuc> <20250112075038.4cd7fc680400e07a32a13f1a@dec.sakura.ne.jp> <Z4L3_BZKnZ2g1CXc@nuc> <20250112111651.e76aea0843ac8f85043c7f10@dec.sakura.ne.jp> <Z4PfaXPhyYxSpe1m@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Jan 2025 10:27:37 -0500 Mark Johnston <markj@freebsd.org> wrote: > 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. Thanks. Will read related codes more deeper to understand once I can take long enough time. -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250113012039.d476e10859c00f7b55f78280>