[ltt-dev] [PATCH tip/core/rcu 1/4] Add header files supporting gcc __sync_ primitives
Paul E. McKenney
paulmck at linux.vnet.ibm.com
Thu Jun 17 12:45:24 EDT 2010
On Thu, Jun 17, 2010 at 03:55:47AM -0400, Paolo Bonzini wrote:
> +#define CACHE_LINE_SIZE 128
> +#define mb() __sync_synchronize()
>
> These are provided by arch_generic.h, aren't they?
>
> In particular, CACHE_LINE_SIZE should be updated there from 64
> to 128 if we deem that value to be better.
Good point -- I need to prune in favor of arch_generic.h.
Therefore getting rid of both CACHE_LINE_SIZE and mb().
> diff --git a/urcu/uatomic_arch_gcc.h b/urcu/uatomic_arch_gcc.h
> new file mode 100644
> index 0000000..df208bd
> --- /dev/null
> +++ b/urcu/uatomic_arch_gcc.h
> @@ -0,0 +1,48 @@
> +/* xchg */
> +#define uatomic_xchg(addr, v) __sync_lock_test_and_set(addr, v)
>
> __sync_lock_test_and_set may only support v==1, and is only
> an acquire barrier, so I think it's better to just use the
> definition in uatomic_arch_generic.h.
Good point -- I clearly am still catching up with the autoconf
changes to this library! Thank you for bearing with me here.
> +/* cmpxchg */
> +#define uatomic_cmpxchg(addr, old, _new) \
> + __sync_val_compare_and_swap(addr, old, _new)
> +
> +/* uatomic_add_return */
> +#define uatomic_add_return(addr, v) __sync_add_and_fetch(addr, v)
>
> These are also provided by uatomic_arch_generic.h.
What I will do is define both UATOMIC_HAS_ATOMIC_BYTE and
UATOMIC_HAS_ATOMIC_SHORT in uatomic_arch_gcc.h, which allows
leveraging uatomic_arch_generic.h -- no other definitions required.
Of course, the same applies to the ARM stuff...
So letting arch_generic.h define CACHE_LINE_SIZE. I need to keep mb()
in arch_armv7l.h due to the compiler bug. At some point, I should
make this depend on __GNUC__, __GNUC_MINOR__, and __GNUC_PATCHLEVEL__.
Given that ARM supports atomic operations on all sizes up to 32 bits,
seems simplest to just supply the bare __sync_ definitions, so will
leave uatomic_arch_armv7l.h as is for the moment.
Will respin, test, and resend!
Thanx, Paul
More information about the lttng-dev
mailing list