From nobody Wed Jan 08 21:31:16 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 4YT1M04B2Wz5k0tV for ; Wed, 08 Jan 2025 21:31:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YT1Lz2vvwz4XLS for ; Wed, 8 Jan 2025 21:31:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="KpH/2iOg"; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=markjdb@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none) Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-844e12f702dso7370539f.3 for ; Wed, 08 Jan 2025 13:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736371881; x=1736976681; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=qSMBhTCfXvDIMjFvxAU6aslAJ5IzJa/QmF49Mx1EiLc=; b=KpH/2iOglyRNOZWTYVAH9MFzCPvH7lnCrU7yc00XtdOGm9SUtw9ogVSprnrKfh654C ghDXF9QAyZJ6zsIzamY4JNWIcgommUOoiHfgFCrhwBm9P+7lhdb+F2QPKvjFJwQW+N40 vtyXRjXRUpA5eGBuRDYyE7JE52nw6VzPN0W2cIfURSpfOkm23hPJMN9LSFC6PEIfsRdq CEHDTKqiNp3F5lwED7fAtkeOTNx9K+Hmiibz4QKcIVcVP9SnQLwN1l9dzmRA5LTICcye IschJHvdq1E5BWgWoZ5DqO9mHXijQeRyd7KuPoZhMyBAqpeAhOHh9ZK0IBVuiEZ5lFuV 7xCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736371881; x=1736976681; h=content-disposition:mime-version:message-id:subject:to:from:date :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qSMBhTCfXvDIMjFvxAU6aslAJ5IzJa/QmF49Mx1EiLc=; b=mRTtYh5K6YqX67poKKr6dZC+Ej8mxAt8HwVesjRFr/sReFCKA2qapJNAibuiyPiAPG IF4AyxNlHfEFq8nV0XUmp7naCe7N544PO6nP65+0NIacYSv5z6BA8VGnwmmgX0urZ7BT sJc5vbbQnHtEkE0ExSXyrdPljwAv6+bYmyJQvjdDZYtv2iBQ21TAPRLh+klq6g3eATMi M+SC9FOIFlKFMWeE0/+6BASey4NDbWIAD38uZ981WKqxwHQ72q7S8pk5mDNgLjZapNL8 OkKkaHOCIj4wb52/yAUjNzmfM6JGxVULioruOPFrLdwMYB2Ywxf/XIVp5DijL/hTkpgR CXcA== X-Gm-Message-State: AOJu0YyXT+SV+edjKohdAI/7adVc5UxCdpHbInAk0ziOkLw8mguu45Wn sMqMoWP3wS0KTQZJY5cFDgejQfqnx7PKELmTkU3rer8nz2ZWx8bft7hj3A== X-Gm-Gg: ASbGncutkcv2Ft5z/3wU75BLl65FrY435ITClDTXTCcQ3y7R4JaWLdqWLhKfxQ3SbAV OY7KzOL7wVv446FMsNomsnQAV3a4IjeWwni6TGjPdnZeEfuS/76uTozds6zUF6pBEROWI2GjpgI 9m4DxVHeqBgspxd6MraOWuq3T547zOoC7/P8PgTkoiDNbkyBKyFNUaIY1ofeCX5Z+BOJQORh2m/ 9uGdsmMxde9QiIs+HOAf3kVlsjmzJZke2mLb2PK4Xl7hfF5N1ZeX1QRIuLJkUwvl9c/MQQ= X-Google-Smtp-Source: AGHT+IFINarUfpPBp+BQ0fvlmUu2inaZKD1dGwnFWvovqUWFKYgLa/bn42cN1ibsRdRJm7/5e8EBeg== X-Received: by 2002:a05:6602:381b:b0:835:45f9:c2ee with SMTP id ca18e2360f4ac-84ce00f6671mr463521439f.4.1736371881211; Wed, 08 Jan 2025 13:31:21 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-84d4fb3f68bsm318939f.20.2025.01.08.13.31.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 13:31:19 -0800 (PST) Date: Wed, 8 Jan 2025 16:31:16 -0500 From: Mark Johnston To: freebsd-hackers@freebsd.org Subject: widening ticks Message-ID: 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-Disposition: inline X-Rspamd-Queue-Id: 4YT1Lz2vvwz4XLS X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d32:from] 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?