From nobody Sat Jan 11 04:11:06 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YVRLs6wd7z5lGYk for ; Sat, 11 Jan 2025 05:06:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YVRLp684jz4fCw; Sat, 11 Jan 2025 05:06:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dec.sakura.ne.jp header.s=s2405 header.b=VWZuRmqz; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 50B4B6kJ086444; Sat, 11 Jan 2025 13:11:08 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1736568668; bh=BvBH9PpTJzunYp3IKQ3rkyQjrbuzr7LsQgsNUhceruA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VWZuRmqzR2Vr9lplmaN+N+EJMaroIWHdKFxQeevSRqfFTr2opJ9sl0R4tBazwo1J2 mtSp0xJFuXQcqtLgunUYHhQFhJsF4w/yIM37ZGB4vcIPAPiQ9JPEXunVHnFMDPC76e GXa3AVU31aqYO1pK16dtuXEmUo95OLa4hCcn97tc= Date: Sat, 11 Jan 2025 13:11:06 +0900 From: Tomoaki AOKI To: Mark Johnston Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-Id: <20250111131106.4d2657de20eeed7eef5c0b15@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YVRLp684jz4fCw X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.29 / 15.00]; URIBL_RED(3.50)[dec.sakura.ne.jp:dkim]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.908]; MV_CASE(0.50)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; HAS_ANON_DOMAIN(0.10)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; HAS_ORG_HEADER(0.00)[]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; ARC_NA(0.00)[]; GREYLIST(0.00)[pass,body]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28:c]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; TO_DN_SOME(0.00)[] On Wed, 8 Jan 2025 18:07:47 -0500 Mark Johnston wrote: > On Thu, Jan 09, 2025 at 12:18:48AM +0200, Konstantin Belousov wrote: > > On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > > > The global "ticks" variable counts hardclock ticks, it's widely used in > > > the kernel for low-precision timekeeping. The linuxkpi provides a very > > > similar variable, "jiffies", but there's an incompatibility: the former > > > is a signed int and the latter is an unsigned long. It's not > > > particularly easy to paper over this difference, which has been > > > responsible for some nasty bugs, and modifying drivers to store the > > > jiffies value in a signed int is error-prone and a maintenance burden > > > that the linuxkpi is supposed to avoid. > > > > > > It would be nice to provide a compatible implementation of jiffies. I > > > can see a few approaches: > > > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > > > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > > > platforms. This is the simplest to implement, but it adds extra work > > > to hardclock() and is somewhat ugly. > > > - Make ticks an int64_t or a long and convert our native code > > > accordingly. This is cleaner but requires a lot of auditing to avoid > > > introducing bugs, though perhaps some code could be left unmodified, > > > implicitly truncating the value to an int. For example I think > > > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > > > and boot with this change, but it's hard to be confident in it. This > > > approach also has the potential downside of bloating structures that > > > store a ticks value, and it can't be MFCed. > > > - Introduce a 64-bit ticks variable, ticks64, and > > > #define ticks ((int)ticks64). This requires renaming any struct > > > fields and local vars named "ticks", of which there's a decent number, > > > but that can be done fairly mechanically. > > > > > > Is there another solution which avoids these pitfalls? If not, should > > > we go ahead with one of these approaches? If so, which one? > > > > You cannot do this in C, but can in asm: > > .data > > .globl ticksl, ticks > > .type ticksl, @object > > .type ticks, @object > > ticksl: .quad > > .size ticksl, 8 > > ticks =ticksl /* for little-endian */ > > /* ticks =ticksl + 4 for big-endian */ > > .size ticks, 4 > > > > > > Then update only ticksl in the hardclock(). > > I implemented your suggestion here: https://reviews.freebsd.org/D48383 As this is already committed to main, commenting here instead of review D48383. Maybe I'm too paranoid and overlooking something, but... *If "jiffies" in LinuxKPI is really unsigned, isn't there any possibilities that relies on its value to be larger than 0x7fffffffffffffff as a threshold? (Yes, it should be silly and non-realistic, but theoretically possible.) *Is anywhere checking carry (sign) bit for int on LP32? Maybe it would be the reason if "jiffies" in LinuxKPI is really unsigned. Regards. -- Tomoaki AOKI