From nobody Wed Jan 08 22:22:26 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 4YT2Tz56BTz5k5Yy for ; Wed, 08 Jan 2025 22:22:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 4YT2Ty6LLDz4hjs for ; Wed, 8 Jan 2025 22:22:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x136.google.com with SMTP id e9e14a558f8ab-3ab29214f45so774545ab.0 for ; Wed, 08 Jan 2025 14:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736374949; x=1736979749; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=98uZ3nSChqgR2S47H+qJ0IciOZvzmRPNf72LkvCvQuo=; b=O/d2uxk+ImMYLGDfud/I34Vd+ffGpHgDFWAnAv1cPEriuiY/VAyEBLwQyiHSHCq9AL 9f3WcoK3ggqHrP+NYEHq9B/z1fvXaJVoxYtIeQmi59NNv3AHF0nsaegZ7+1LPuvHKFiu 5Lk+WeUBXEEQkLThTEDg/nGTNharnRNkhnnQvigxbD3ZqjUrz/wMvPLvggeh/GVJuQVw 4FMDE17SCwBz4qbwmOxNdvDrmR4PvEu1Exm59wv+K7Nt3DXkO+UcD8foISe/x62hnQ68 TrftwRChmxNnXbN3wJ1AlYIckgn2mWwAnufUuWdPC/Aeg+ktmjieMRvGrzF9NkfqatwX SZIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736374949; x=1736979749; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=98uZ3nSChqgR2S47H+qJ0IciOZvzmRPNf72LkvCvQuo=; b=mKear3WX6ozhqZE0kyEfTge1Wc+XPZsTzjKI35E++WCsTr7NGI7hgdoZQrpXHRAhwt nDqKf4kxU8pIG6F21lEd7HD1cQHYMFka0SeKPqvOS9sh7h/twU6Fmc2ORUQJd7XOKY1y StV98/v1y6PwlhMtfdvRgbN4S18Yy/PdZzporAtK8dAGkOeTcO7+D3w9ZEMtnk96z6lE ie6Od6WSzao9E2Cj5WzspFHrI55IGU/k3UZuSAX/xIBqihjkOA7T+KLYScpgbizaecIM 9IftZD2Ac2cTSgh27Xq+iB7G/pXQtZ35KEmzaHossp2diaes4e/pz8SysK0VjWq72mkZ znTw== X-Gm-Message-State: AOJu0Yy84Gn2ESsXojHb7/dfTwTTRAv78pTJaQKwwspeEa5mNIt6xOU1 K/MkMMMTjglnDSWu75Wnz9VCFh9nWoUvQMb2j5bsZM/8n5XRVxuPp8J6ow== X-Gm-Gg: ASbGncv18n7l9gIrWLeYCW5e5lKXNxcq5lcW+bK/9uydpaR38q1NSbs2/22D8bOsj/j 4xH1UYDSVcScMC4jDIvoUX2v0o+lBH+AGHKMlBEVurn6EkANtc/Lt9oJ8n4eDhcQcrdpvFj99E9 JFIrpAGBengDbUdQ4X23IPEbCHO19cs5WkgJTLnUzRn28dSjwM7NKhI12cxnozqFqtbqYKeNGWa rv12MN8mhHphg1CTi/ZXYFNxuaRwYOMEzyeTLMtL52iS/fL7vKxnvPc4/sqafEzvwqfOCM= X-Google-Smtp-Source: AGHT+IH6+7YUi5w3j95MxDRTkF+rI1JuJVq6qV+XCDlh0o12Ws7soWr+JD0n86FZEhnor2FBVe++Ag== X-Received: by 2002:a92:c243:0:b0:3a7:87f2:b010 with SMTP id e9e14a558f8ab-3ce3a9a5743mr37774435ab.5.1736374949528; Wed, 08 Jan 2025 14:22:29 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e68bf67546sm10784462173.42.2025.01.08.14.22.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2025 14:22:29 -0800 (PST) Date: Wed, 8 Jan 2025 17:22:26 -0500 From: Mark Johnston To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: widening ticks Message-ID: References: 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 In-Reply-To: X-Rspamd-Queue-Id: 4YT2Ty6LLDz4hjs X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] 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(). Oh, that's better than my proposals. I guess it could be done in the kernel linker script too, but perhaps locore.S is a better place anyway.