[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b0acc4c-6ba9-4743-bad7-2baa1e29b085@paulmck-laptop>
Date: Thu, 2 May 2024 16:45:29 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
elver@...gle.com, akpm@...ux-foundation.org, tglx@...utronix.de,
peterz@...radead.org, dianders@...omium.org, pmladek@...e.com,
arnd@...db.de, torvalds@...ux-foundation.org, kernel-team@...a.com,
Andi Shyti <andi.shyti@...ux.intel.com>,
Palmer Dabbelt <palmer@...osinc.com>,
Masami Hiramatsu <mhiramat@...nel.org>, linux-sh@...r.kernel.org
Subject: Re: [PATCH v2 cmpxchg 12/13] sh: Emulate one-byte cmpxchg
On Fri, May 03, 2024 at 12:24:47AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 04:12:44PM -0700, Paul E. McKenney wrote:
>
> > > I'm probably missing your point, though - what mix of cmpxchg and
> > > smp_store_release on 8bit values?
> >
> > One of RCU's state machines uses smp_store_release() to start the
> > state machine (only one task gets to do this) and cmpxchg() to update
> > state beyond that point. And the state is 8 bits so that it and other
> > state fits into 32 bits to allow a single check for multiple conditions
> > elsewhere.
>
> Humm... smp_store_release() of 8bit on old alpha is mb + fetch 64bit + replace
> 8 bits + store 64bit...
Agreed, which is why Arnd is moving his patches ahead. (He and I
discussed this some weeks back, so not a surprise for him.)
For my part, I dropped 16-bit cmpxchg emulation when moving from the
RFC series to v1.
Thanx, Paul
Powered by blists - more mailing lists