From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 57C8BC27C53 for ; Sat, 15 Jun 2024 22:12:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VQbZ8odua1hQgPb+pK/nZMpMy6s0hU++zOMWAbph2Ak=; b=iMby6fTQdJPQefUlNZitHZY/gl S0e2wW7RInmnTqKT4MnZBJlJACxAIAjbVKQlgPxQoF7kxjAvnqv0hJ8v5AANVsjdUSCINJ98Wbcur 5zZyB4+d273OkcRufZQn0nXF6Z4fR00Pev2fqsRFDXnA0jHwDKzeW5qV6eNBFuBgVbJSh2JkCgI2N Q8/uRv0ZXKlqvbY9jsl4QRAL1cdF88wOz5sxDkmw7vD06PkHQBoi5F0e8YD+zdhVBJDPew60JKrWz QSmU3CZ99sjJKyqz+WOJqYyKLmDRetjqM7LheufwJO6vO8jSw/Ort7U1+encrhuvo9kasCgU7JIwj v6KkZQwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sIbdc-00000006BpN-0QTU; Sat, 15 Jun 2024 22:12:44 +0000 Received: from mail-qv1-xf36.google.com ([2607:f8b0:4864:20::f36]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sIbdZ-00000006Bni-0fXt for linux-arm-kernel@lists.infradead.org; Sat, 15 Jun 2024 22:12:42 +0000 Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6b09072c9d9so26347356d6.1 for ; Sat, 15 Jun 2024 15:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718489558; x=1719094358; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:from:to:cc:subject:date:message-id:reply-to; bh=VQbZ8odua1hQgPb+pK/nZMpMy6s0hU++zOMWAbph2Ak=; b=TXCKb+pGZA+4G55PFEXz+kl4nIiV7G90eCd1eyZy0pfzLc256NnbsQH4mJgcGH8iOP pqdNn8J4MdYOdaJU8yC40dE0mJUZxhUGYWUmC+utbnFwjv72pH/LjBD2/yg93L2aE5L5 nVFMKzOwirFGjhI6S2+bCFHU1AdCldaDIUaevUwqdgmd41caulkqgx/qCFvCyPcPU9FX MhS5FOdg8xWAvadwDNWmrodsMKDPTCdU0ozhQDZmhP9nGDrwE5MzLkM2iXo2jdWnsCEe +qwazN/AeQ3+HsPS/LN9Ymx8fpdAKljhTLhT/GIEIsFVQ+l+5k2fupSOjBe+7XwLJYFm /mHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718489558; x=1719094358; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VQbZ8odua1hQgPb+pK/nZMpMy6s0hU++zOMWAbph2Ak=; b=fjMJ/h0Wh0/CLx675eu9V8H5QAJhYehiccbSfg5UhJE14bzshqsOioddbowmaquNfU eigxSZAJQGl9V67nZX1Wrjn+CtmyVd3g5Ea+kuooEjSslqEq92FsCyX6cM20t0uiEjjC e+UIXr8l4lwEYDaOdT+Ba++qxZP0s3Hxa8yeiObGCGtNdnaIFIhStD8Uor1XdrSn0LKm L/9SxiONluVwTCOtDP3WWMIEG0cNZP9IzQL7EFPpVVKngc5amd3qA9+2Ce6jbAGQKzp1 YbDCN5IXfnDm+tDDGbVblqb7Z20vFN/RASjeZKU7PyXIFV+V+gkOD8VWugXxyzbGhxyQ joqQ== X-Forwarded-Encrypted: i=1; AJvYcCU4D+cLlATmWrXaubu565Hp4UQcJbvj8frJd1A4A881v6b0yhCTYCBe6ul4qZ2it+hmcs3ra/2hdCrbvKVVf4HL4kyShsh7MEav9/yxI9jmJElKAa8= X-Gm-Message-State: AOJu0YyN5f+WurODYoBSBTwFaIoD2Y902i0GbLoN8JaF2gKvp8NqCAAo ufNIdBZ0TT+T2iNQEfgZQgTO6bQgNCOnBgCI1yJ0ZE67g1ypzYfZ X-Google-Smtp-Source: AGHT+IG4HmvNaRjIhMLhZmWvrLBxGBdGzpx8lIGc5erMmHO1rw2wmIF90qlwEKwxcvp0aYOUU1vmBA== X-Received: by 2002:a0c:c486:0:b0:6af:33ed:87de with SMTP id 6a1803df08f44-6b2af2eef89mr96166876d6.20.1718489557589; Sat, 15 Jun 2024 15:12:37 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b2a5ee01d9sm36048266d6.111.2024.06.15.15.12.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jun 2024 15:12:36 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfauth.nyi.internal (Postfix) with ESMTP id BB4DA120006D; Sat, 15 Jun 2024 18:12:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 15 Jun 2024 18:12:35 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvvddgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpeeuohhq uhhnucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepvefghfeuveekudetgfevudeuudejfeeltdfhgfehgeekkeeigfdukefh gfegleefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epsghoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedt ieegqddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfh higihmvgdrnhgrmhgv X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 15 Jun 2024 18:12:34 -0400 (EDT) Date: Sat, 15 Jun 2024 15:12:33 -0700 From: Boqun Feng To: Benno Lossin Cc: Miguel Ojeda , Gary Guo , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, llvm@lists.linux.dev, Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Andreas Hindborg , Alice Ryhl , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Nathan Chancellor , Nick Desaulniers , kent.overstreet@gmail.com, Greg Kroah-Hartman , elver@google.com, Mark Rutland , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Catalin Marinas , torvalds@linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, Trevor Gross , dakr@redhat.com Subject: Re: [RFC 2/2] rust: sync: Add atomic support Message-ID: References: <20240612223025.1158537-3-boqun.feng@gmail.com> <20240613144432.77711a3a@eugeo> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240615_151241_226793_ABA36912 X-CRM114-Status: GOOD ( 47.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Jun 15, 2024 at 07:09:30AM +0000, Benno Lossin wrote: > On 15.06.24 03:33, Boqun Feng wrote: > > On Fri, Jun 14, 2024 at 09:22:24PM +0000, Benno Lossin wrote: > >> On 14.06.24 16:33, Boqun Feng wrote: > >>> On Fri, Jun 14, 2024 at 11:59:58AM +0200, Miguel Ojeda wrote: > >>>> On Thu, Jun 13, 2024 at 9:05 PM Boqun Feng wrote: > >>>>> > >>>>> Does this make sense? > >>>> > >>>> Implementation-wise, if you think it is simpler or more clear/elegant > >>>> to have the extra lower level layer, then that sounds fine. > >>>> > >>>> However, I was mainly talking about what we would eventually expose to > >>>> users, i.e. do we want to provide `Atomic` to begin with? If yes, > >>> > >>> The truth is I don't know ;-) I don't have much data on which one is > >>> better. Personally, I think AtomicI32 and AtomicI64 make the users have > >>> to think about size, alignment, etc, and I think that's important for > >>> atomic users and people who review their code, because before one uses > >>> atomics, one should ask themselves: why don't I use a lock? Atomics > >>> provide the ablities to do low level stuffs and when doing low level > >>> stuffs, you want to be more explicit than ergonomic. > >> > >> How would this be different with `Atomic` and `Atomic`? Just > > > > The difference is that with Atomic{I32,I64} APIs, one has to choose (and > > think about) the size when using atomics, and cannot leave that option > > open. It's somewhere unconvenient, but as I said, atomics variables are > > different. For example, if someone is going to implement a reference > > counter struct, they can define as follow: > > > > struct Refcount { > > refcount: AtomicI32, > > data: UnsafeCell > > } > > > > but with atomic generic, people can leave that option open and do: > > > > struct Refcount { > > refcount: Atomic, > > data: UnsafeCell > > } > > > > while it provides configurable options for experienced users, but it > > also provides opportunities for sub-optimal types, e.g. Refcount: > > on ll/sc architectures, because `data` and `refcount` can be in the same > > machine-word, the accesses of `refcount` are affected by the accesses of > > `data`. > > I think this is a non-issue. We have two options of counteracting this: > 1. We can just point this out in reviews and force people to use > `Atomic` with a concrete type. In cases where there really is the > need to be generic, we can have it. > 2. We can add a private trait in the bounds for the generic, nobody > outside of the module can access it and thus they need to use a > concrete type: > > // needs a better name > trait Integer {} > impl Integer for i32 {} > impl Integer for i64 {} > > pub struct Atomic { > /* ... */ > } > > And then in the other module, you can't do this (with compiler error): > > pub struct Refcount { > // ^^^^^^^ not found in this scope > // note: trait `crate::atomic::Integer` exists but is inaccessible > refcount: Atomic, > data: UnsafeCell, > } > > I think that we can start with approach 2 and if we find a use-case > where generics are really unavoidable, we can either put it in the same > module as `Atomic`, or change the access of `Integer`. > What's the issue of having AtomicI32 and AtomicI64 first then? We don't need to do 1 or 2 until the real users show up. And I'd like also to point out that there are a few more trait bound designs needed for Atomic, for example, Atomic and Atomic have different sets of API (no inc_unless_negative() for u32). Don't make me wrong, I have no doubt we can handle this in the type system, but given the design work need, won't it make sense that we take baby steps on this? We can first introduce AtomicI32 and AtomicI64 which already have real users, and then if there are some values of generic atomics, we introduce them and have proper discussion on design. To me, it's perfectly fine that Atomic{I32,I64} co-exist with Atomic. What's the downside? A bit specific example would help me understand the real concern here. Regards, Boqun > --- > Cheers, > Benno > > > The point I'm trying to make here is: when you are using atomics, you > > care about performance a lot (otherwise, why don't you use a lock?), and > > because of that, you should care about the size of the atomics, because > > it may affect the performance significantly. >