[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150714110811.GE16213@arm.com>
Date: Tue, 14 Jul 2015 12:08:11 +0100
From: Will Deacon <will.deacon@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"Waiman.Long@...com" <Waiman.Long@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 1/5] atomics: add acquire/release/relaxed variants of
some atomic operations
On Tue, Jul 14, 2015 at 11:58:37AM +0100, Peter Zijlstra wrote:
> On Tue, Jul 14, 2015 at 11:32:20AM +0100, Will Deacon wrote:
> > On Tue, Jul 14, 2015 at 11:25:11AM +0100, Peter Zijlstra wrote:
> > > Could we not define _{acquire,release} in terms of _relaxed and
> > > smp_mb__{after,before}_atomic() ?
> >
> > I actually started out with that, but it penalises architectures that
> > don't have _relaxed implementations of some routines.
>
> #ifndef atomic_add_return_relaxed
>
> #define atomic_add_return_relaxed atomic_add_return
> /*
> * If one cannot define a more relaxed version,
> * acquire/release are out the window too.
> */
> #define atomic_add_return_acquire atomic_add_return
> #define atomic_add_return_release atomic_add_return
>
> #else /* relaxed */
>
> #ifndef atomic_add_return_acquire
> #define atomic_add_return_acquire(args...) \
> do { \
> atomic_add_return_relaxed(args); \
> smp_mb__after_atomic(); \
> } while (0)
> #endif
>
> #ifndef atomic_add_return_release
> #define atomic_add_return_release(args...) \
> do { \
> smp_mb__before_atomic(); \
> atomic_add_return_relaxed(args); \
> } while (0)
> #endif
>
> #endif /* relaxed */
If a picture is worth a thousand words, a patch is worth at least a thousand
pictures.
I'll add this for v2.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists