From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F785223339 for ; Sun, 4 Jan 2026 08:36:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767515820; cv=none; b=SDLEz3cSyVXjBU0Haw/wBhiFnzaF0e1wFyoHA5E/NRlHw/x8O+ABkSO+sPQnoLAQXYxiWwf/3P7OiDHXBNmB0pQfLNsZPXqtGVlvK/+WuatxEPsip4ii0SBz3GZcaSfnE9db8ZXI+xw3OLEmq2P2sHBRniPa685AO/e+4V6vKCg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767515820; c=relaxed/simple; bh=61t4IgEPCUvsgF7eRrP54u+CuLdFavfMVw2A6bqiYWE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X/5M3H0E09Fk6Q8Q7z/sUypFIALoosFrN2lioMOA/Fzb2MNKgdLFm2o499u1eO6sS0aeOxV0Hd3D0uEXVrRFk4qxrtK+O7ZnVXRDOeEB8fJV/MEI7UY7Hk4xEp6ucWp6PQUtTDL82I8O99oXlVFfKuyL7h0fooN+Jzp75RRXwpc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=F5Vv3wdH; arc=none smtp.client-ip=209.85.222.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F5Vv3wdH" Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-8b2148ca40eso2133827585a.1 for ; Sun, 04 Jan 2026 00:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767515818; x=1768120618; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=lIx/9Xfz3imVI1It6iljITXfA4Emto3M5fiv93Vq6us=; b=F5Vv3wdHmwTyOBO2B9MLgH54uzb3t5q0vTF85mDLZNMRNtG7M6WobU6UK0KLqmM/2D 1BRivEUzDCj+GoijNvA3VWgwTZYWvjNPMVSRQRVu8ZAM7fvQ0nisTHQkdd/WBGgp37WE 7R2YB1Rgs7QGgrxMaByh464Y2SCriYeaxSrRQp30XUNrwu4e8g0+g9kwwU4fBp9lxjNS lxfYscmBPQFgCedXW9nvLd+cO0HxvTIq4zJzRtTjcorxEqIlXaPXo5FTxeh5Qe8TS++p YNDX6BiSK0ZKE2VcSNj+yZfkXGrLweX6dpo7DwhmkG/TjN+HE+bf6c0NVny4YRobeWvs F3Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767515818; x=1768120618; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=lIx/9Xfz3imVI1It6iljITXfA4Emto3M5fiv93Vq6us=; b=FHY/wgYnkFbQZaCZNJBhHS4JCOSuRbdIg3bX6rbQZ0FceDurgETKo515wsfpKQtyQ8 olYIgiEfcZk0/akp+2GSV1qUzSPDpXEUszUf+8MVepx3eST/KQiV3WBLrTmHfHBzkPNh 9J9ewKeOSOtEFmLVoHwWVNQ/B8OC6JgtoBdbGGydAMqUTDTyLPnn4aDVGg2KvpAZQLQy 2Ej0iDwMW8HjDM6S4i+0L83L1y8Eco317nS2NFYKZH7iyml35tBe4wbf9FDBUQWHOwdh OnsXOB1lTBF367NuB7rd+8tteVHM2iwb1wgNa5TwVfzTqr71Sk40VQgspnTgoe46F57S uaFA== X-Forwarded-Encrypted: i=1; AJvYcCWgYcO4PPxY2HZdZA13CtnVjFgXBuzRHgP0pm4xCLh+mK5kvdyF3hHefCU+Qu3v1HdG43qoZYB2jeeG8oOcQg==@vger.kernel.org X-Gm-Message-State: AOJu0YxeGLHgppVVzWedI3KGb6b6YMczZTkgEfp+WhmJ5vvAfu39Jwki 9gGPBe+38wm5K3xoCtOqWbYPhowZurLKmhmloSYdC+mPoik8JGjv6Y+9 X-Gm-Gg: AY/fxX4wkfTMkn5Au7kfvYpFEtWdCrYtV/9ma3mmEcOKnBwyX9Z/UobNy/xiyzGcHSk s01xbLH80ZMwIV41Vt2hIM0P6HKIw1q9x5b0FEIC/uOsEi5/EVn0soX53MHUUbYlaj8Df06SQud r9qy9GHDxAdrL/u/BdGwLWBm1uijQYtQGzXaO7KCrZb0oEd2yB5UC4FkQPzStBYnINfzdRY3HAJ QkAqK0a4SYwQNHBbDNPwRpyKXCbPzt1L3GPdn+kM/zosZvs1mXl6QyUAjDhRmcpjvECKP/VaWzZ VUx5YE6S+3Ubp7qypPdXGaYrDp+zb6wCRj7KHGKsUPVsyfrD6Quu9Cnn5dF91dgo8nD18kf/DeG e8YYDdhIuH6R4S7auOmmdEP8y8slb6gMFsXC/oW0A2QFxclpLJdp6keWTYHJT9h2Mv5MXAQT1t0 qWso6kJvC+6mwrstgXP0KR0Xn0ML3DrissTtgNMLCdVLncI7HOQYpZja5WmyThxkRPD6ezuDfEo z7iNxv5qx5UnXE= X-Google-Smtp-Source: AGHT+IGxI7VAIIXWwXK0E7LLLUeHnPckTp5tfwxQkHv/pu4eOzleduA9RWCvaIOTJ2zUoT0n5/6i5Q== X-Received: by 2002:a05:620a:4016:b0:8b2:e922:529a with SMTP id af79cd13be357-8c08fab558emr7237586785a.19.1767515818045; Sun, 04 Jan 2026 00:36:58 -0800 (PST) Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c096a8c2ecsm3470355585a.23.2026.01.04.00.36.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Jan 2026 00:36:57 -0800 (PST) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id BE70CF40068; Sun, 4 Jan 2026 03:36:56 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Sun, 04 Jan 2026 03:36:56 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdelfeeliecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhnucfh vghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrthhtvg hrnhephfetvdfgtdeukedvkeeiteeiteejieehvdetheduudejvdektdekfeegvddvhedt necuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegsohhquhhnodhmvghsmhhtphgruhhthhhpvghr shhonhgrlhhithihqdeiledvgeehtdeigedqudejjeekheehhedvqdgsohhquhhnrdhfvg hngheppehgmhgrihhlrdgtohhmsehfihigmhgvrdhnrghmvgdpnhgspghrtghpthhtohep udefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehfuhhjihhtrgdrthhomhhonh horhhisehgmhgrihhlrdgtohhmpdhrtghpthhtohepghgrrhihsehgrghrhihguhhordhn vghtpdhrtghpthhtohepohhjvggurgeskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprg drhhhinhgusghorhhgsehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrlhhitggvrhih hhhlsehgohhoghhlvgdrtghomhdprhgtphhtthhopegsjhhorhhnfegpghhhsehprhhoth honhhmrghilhdrtghomhdprhgtphhtthhopegurghkrheskhgvrhhnvghlrdhorhhgpdhr tghpthhtoheplhhoshhsihhnsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehtmhhgrh hoshhssehumhhitghhrdgvughu X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 4 Jan 2026 03:36:55 -0500 (EST) Date: Sun, 4 Jan 2026 16:36:53 +0800 From: Boqun Feng To: FUJITA Tomonori Cc: gary@garyguo.net, ojeda@kernel.org, a.hindborg@kernel.org, aliceryhl@google.com, bjorn3_gh@protonmail.com, dakr@kernel.org, lossin@kernel.org, tmgross@umich.edu, acourbot@nvidia.com, rust-for-linux@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH v1] rust: sync: atomic: Add i32-backed Flag for atomic booleans Message-ID: References: <20260101210430.6b210dc6.gary@garyguo.net> <20260103.194448.560764475765900721.fujita.tomonori@gmail.com> <20260103190511.2d267164.gary@garyguo.net> <20260104.065311.609258219418619592.fujita.tomonori@gmail.com> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260104.065311.609258219418619592.fujita.tomonori@gmail.com> On Sun, Jan 04, 2026 at 06:53:11AM +0900, FUJITA Tomonori wrote: [...] > >> > > >> >> Add a new Flag enum (Clear/Set) with #[repr(i32)] and implement > >> >> AtomicType for it, so users can use Atomic for boolean flags. > >> >> > >> >> Document when Atomic is generally preferable to Atomic: in > >> >> particular, when RMW operations such as xchg()/cmpxchg() may be used > >> >> and minimizing memory usage is not the top priority. On some > >> >> architectures without byte-sized RMW instructions, Atomic can be > >> >> slower for RMW operations. > >> >> > >> >> Signed-off-by: FUJITA Tomonori > >> >> --- > >> >> rust/kernel/sync/atomic.rs | 35 +++++++++++++++++++++++++++++++++++ > >> >> 1 file changed, 35 insertions(+) > >> >> > >> >> diff --git a/rust/kernel/sync/atomic.rs b/rust/kernel/sync/atomic.rs > >> >> index 4aebeacb961a..d98ab51ae4fc 100644 > >> >> --- a/rust/kernel/sync/atomic.rs > >> >> +++ b/rust/kernel/sync/atomic.rs > >> >> @@ -560,3 +560,38 @@ pub fn fetch_add(&self, v: Rhs, _: Ordering) > >> >> unsafe { from_repr(ret) } > >> >> } > >> >> } > >> >> + > >> >> +/// An atomic flag type backed by `i32`. > >> > > >> > I would recommend that we document that the backing type is the > >> > (perf-)optimal type on the target architecure, so arch can decide to use > >> > i8 as backing type if they prefer. > >> > >> I'm not sure I fully understand the intent yet. > >> > >> Do you mean we should document Flag as being backed by the > >> (perf-)optimal integer type for the target architecture, so that the > >> backing type can remain an implementation detail and potentially be > >> selected per-arch (e.g. i8 on x86) via cfg? > > > > Yes, I don't want anyone to rely on it being i32 (at least for now, before > > a concrete use case of doing so appears). > > I see, the following comment works for you? > > I thought Boqun had Revocable in mind as the intended use case. > Right, but To me, the most important thing is avoiding the misuse of Atomic. A few cases when using Atomic is not recommended: * when RmW operations can happen * when using Atomic doesn't save memory (because of padding), e.g. SomeData(Atomic, i32) hence the need of Atomic. Therefore Atomic needs to be: 1. performing better in contented cases than Atomic 2. maybe costing more memory than Atomic because of 1 in that sense, I think Gary's suggestion is reasonable (of course, whether the space optimization of Atomic has any actual value remains to see, but it won't hurt to start with the possiblity). FWIW, another usage is for call_once() where you want to use bool for x86 and i32 for riscv, because using bool on riscv can actually cost more memory. [1}: https://lore.kernel.org/rust-for-linux/Zy_oj_k-qUPLSVEr@tardis.local/ Regards, Boqun > /// An atomic flag type. > /// > /// This type is a performance-oriented boolean for atomic operations. > /// The integer type used as the backing representation is an implementation detail, selected to > /// be (perf-)optimal for the target architecture. > /// > /// Currently, [`Flag`] uses an `i32` representation. This is because, on some architectures that > /// do not support byte-sized atomic read-modify-write operations, RMW operations (e.g. > /// `xchg()`/`cmpxchg()`) on `Atomic` can be slower than those on `Atomic`. > /// > /// If you only use `load()`/`store()`, either `Atomic` or `Atomic` is fine. > [...]