From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E984012BF20 for ; Tue, 2 Apr 2024 20:52:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712091133; cv=none; b=ldaewKXHzu0u4z/xpKpxGa3EBN3d8U0Fn5S5ZpvQKAJIG/I+OZ1CsYjsz3+tPxLDwxBkMCQdkx60+hbaEtsWIt62ZtopYoUcksYP8+XRb+IFt0qMMTJPULcHGnrBuPZHt7WhD4XYwjaq7V+y0S8/eLK5JT2FpXcGVmwlrLfg2aw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712091133; c=relaxed/simple; bh=R3Vv/DIHvrty2Q1jbRGDUHTqjO0wMc/8gqvhtFZSArw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rkxz83AU/OOSx6I9mFBKXgScNgMEjD8APOFAUMtU64H/bVNfZl4/l1bsG7tAyJoeQLBUkFX9zhuRoqgljmVvYnOXTScB7zrzCutpyhz3NW2/rzkoymOv5SjJX9HSzzbdegPJWipEiId0Yuy3bqTcaYLzM3b9WNA/S80b0X/PUnE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WVZcjuEZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WVZcjuEZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84274C433F1; Tue, 2 Apr 2024 20:52:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712091132; bh=R3Vv/DIHvrty2Q1jbRGDUHTqjO0wMc/8gqvhtFZSArw=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=WVZcjuEZ43WvEIfkaiwrdoMx0BOJsj+4l1u0IMMqul4n5rMgxWUUQl0Sy3ObQmMg2 Gu5ByVQvRCjwYaokcOhGlFTiQ2LxjWqe/b3+iD1b4B+RI+pI+Tfo5TT4s3IljE0tGw eagYeop4H0txl4QzDYxv0F1cRhK0sQ8+LhEBEe/zqMginFsRmW4fGtO3MQd0D98GPK IUPpzmEAkQ4u2ZIe4A8qLcqnEOllBaOOH4M8VUSMgTYEWAKy+Zr48LsNiCmRB/l4Wt XJGMUNaWztZ9C0x650VLDFXs5bZjhICMpqnGdVH8MGNQjD660bhZmGxHY0Sgqo2J9F agr8e4KeuOM4w== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 1B64ACE0FF2; Tue, 2 Apr 2024 13:52:12 -0700 (PDT) Date: Tue, 2 Apr 2024 13:52:12 -0700 From: "Paul E. McKenney" To: Arnd Bergmann Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, Vineet Gupta , Andi Shyti , Andrzej Hajda , Palmer Dabbelt , linux-snps-arc@lists.infradead.org Subject: Re: [PATCH RFC cmpxchg 3/8] ARC: Emulate one-byte and two-byte cmpxchg Message-ID: <8d92aab3-a3d0-4625-8b97-e336c0c7a2e8@paulmck-laptop> Reply-To: paulmck@kernel.org References: <31c82dcc-e203-48a9-aadd-f2fcd57d94c1@paulmck-laptop> <20240401213950.3910531-3-paulmck@kernel.org> <836df0c7-51a7-4786-8a65-a70efe9b6eec@app.fastmail.com> <32936b57-f451-460b-a2df-e74293e44f5c@paulmck-laptop> Precedence: bulk X-Mailing-List: linux-kernel@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: <32936b57-f451-460b-a2df-e74293e44f5c@paulmck-laptop> On Tue, Apr 02, 2024 at 10:06:14AM -0700, Paul E. McKenney wrote: > On Tue, Apr 02, 2024 at 10:14:08AM +0200, Arnd Bergmann wrote: > > On Mon, Apr 1, 2024, at 23:39, Paul E. McKenney wrote: > > > Use the new cmpxchg_emu_u8() and cmpxchg_emu_u16() to emulate one-byte > > > and two-byte cmpxchg() on arc. > > > > > > Signed-off-by: Paul E. McKenney > > > > I'm missing the context here, is it now mandatory to have 16-bit > > cmpxchg() everywhere? I think we've historically tried hard to > > keep this out of common code since it's expensive on architectures > > that don't have native 16-bit load/store instructions (alpha, armv3) > > and or sub-word atomics (armv5, riscv, mips). > > I need 8-bit, and just added 16-bit because it was easy to do so. > I would be OK dropping the 16-bit portions of this series, assuming > that no-one needs it. And assuming that it is easier to drop it than > to explain why it is not available. ;-) > > > Does the code that uses this rely on working concurrently with > > non-atomic stores to part of the 32-bit word? If we want to > > allow that, we need to merge my alpha ev4/45/5 removal series > > first. > > For 8-but cmpxchg(), yes. There are potentially concurrent > smp_load_acquire() and smp_store_release() operations to this same byte. > > Or is your question specific to the 16-bit primitives? (Full disclosure: > I have no objection to removing Alpha ev4/45/5, having several times > suggested removing Alpha entirely. And having the scars to prove it.) > > > For the cmpxchg() interface, I would prefer to handle the > > 8-bit and 16-bit versions the same way as cmpxchg64() and > > provide separate cmpxchg8()/cmpxchg16()/cmpxchg32() functions > > by architectures that operate on fixed-size integer values > > but not compounds or pointers, and a generic cmpxchg() wrapper > > in common code that can handle the abtraction for pointers, > > long and (if absolutely necessary) compounds by multiplexing > > between cmpxchg32() and cmpxchg64() where needed. > > So as to support _acquire(), _relaxed(), and _release()? > > If so, I don't have any use cases for other than full ordering. Nor any use cases other than integers. (In case another thing you are after here is good type-checking for non-integers combined with allowing C-language implicit conversions for integers.) Thanx, Paul > > I did a prototype a few years ago and found that there is > > probably under a dozen users of the sub-word atomics in > > the tree, so this mostly requires changes to architecture > > code and less to drivers and core code. > > Given this approach, the predominance of changes to architecture code > seems quite likely to me. > > But do we really wish to invest that much work into architectures that > might not be all that long for the world? (Quickly donning my old > asbestos suit, the one with the tungsten pinstripes...) > > Thanx, Paul