[PATCH 5/9] locking/qrwlock: remove redundant cmpxchg barriers on writer slow-path
Will Deacon
will.deacon at arm.com
Wed Jul 8 06:34:03 PDT 2015
On Wed, Jul 08, 2015 at 11:05:26AM +0100, Peter Zijlstra wrote:
> On Tue, Jul 07, 2015 at 06:24:21PM +0100, Will Deacon wrote:
> > +#ifndef cmpxchg_relaxed
> > +# define cmpxchg_relaxed cmpxchg
> > +#endif
>
> Should we collate this _relaxed stuff and make it 'official' instead of
> these ad-hoc/in-situ things?
>
> There's more archs that can usefully implement them than seem to have
> implemented them atm. Of course that means someone doing a full arch/*
> sweep, but hey.. :-)
Well, in writing this series, I'm seeing a repeated need for:
* acquire/release/relaxed variants of cmpxchg
* acquire/relaxed atomic_add_return
* acquire/release atomic_sub
I also suspect that if I look at getting qspinlock up and running, the
list above will grow.
So you're right, but it sounds like we need to extend the atomic APIs to
have acquire/release/relaxed variants. The easiest start would be to
extend the _return variants (+cmpxchg) to allow the new options, but
defaulting to the existing (full barrier) implementations if the arch
doesn't provide an alternative. Weird things like dec_if_positive could
be left alone (i.e. not implemented) for now.
The hard part is defining the semantics of these new flavours. Do we want
SC acquire/release (i.e. what we have on arm64) or PC acquire/release (i.e.
what we have in C11)? For architectures building these constructs out of
barrier instructions, the former requires an additional barrier following
a release operation so that it is ordered against a subsequent acquire.
Another potential problem of defining things this way is cmpxchg_acquire
potentially giving relaxed semantics if the comparison fails (different
to C11, iirc).
Anyway, clearly a separate series. Should keep me busy...
Will
More information about the linux-arm-kernel
mailing list