On Wed, May 14, 2008 at 06:35:11AM +0200, Nick Piggin wrote:
> read_barrie_depends has always been a noop (not a compiler barrier) on all
> architectures except SMP alpha. This brings UP alpha and frv into line with all
> other architectures, and fixes incorrect documentation.
One update for the documentation update.
Thanx, Paul
> Signed-off-by: Nick Piggin <npiggin@xxxxxxx>
> Acked-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
>
> ---
> Documentation/memory-barriers.txt | 12 +++++++++++-
> include/asm-alpha/barrier.h | 2 +-
> include/asm-frv/system.h | 2 +-
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/include/asm-alpha/barrier.h
> ===================================================================
> --- linux-2.6.orig/include/asm-alpha/barrier.h
> +++ linux-2.6/include/asm-alpha/barrier.h
> @@ -24,7 +24,7 @@ __asm__ __volatile__("mb": : :"memory")
> #define smp_mb() barrier()
> #define smp_rmb() barrier()
> #define smp_wmb() barrier()
> -#define smp_read_barrier_depends() barrier()
> +#define smp_read_barrier_depends() do { } while (0)
> #endif
>
> #define set_mb(var, value) \
> Index: linux-2.6/include/asm-frv/system.h
> ===================================================================
> --- linux-2.6.orig/include/asm-frv/system.h
> +++ linux-2.6/include/asm-frv/system.h
> @@ -179,7 +179,7 @@ do { \
> #define mb() asm volatile ("membar" : : :"memory")
> #define rmb() asm volatile ("membar" : : :"memory")
> #define wmb() asm volatile ("membar" : : :"memory")
> -#define read_barrier_depends() barrier()
> +#define read_barrier_depends() do { } while (0)
>
> #ifdef CONFIG_SMP
> #define smp_mb() mb()
> Index: linux-2.6/Documentation/memory-barriers.txt
> ===================================================================
> --- linux-2.6.orig/Documentation/memory-barriers.txt
> +++ linux-2.6/Documentation/memory-barriers.txt
> @@ -994,7 +994,17 @@ The Linux kernel has eight basic CPU mem
> DATA DEPENDENCY read_barrier_depends() smp_read_barrier_depends()
>
>
> -All CPU memory barriers unconditionally imply compiler barriers.
> +All memory barriers except the data dependency barriers imply a compiler
> +barrier. Data dependencies do not impose any additional compiler ordering.
> +
> +Aside: In the case of data dependencies, the compiler would be expected to
> +issue the loads in the correct order (eg. `a[b]` would have to load the value
> +of b before loading a[b]), however there is no guarantee in the C specification
> +that the compiler may not speculate the value of b (eg. is equal to 1) and load
> +a before b (eg. tmp = a[1]; if (b != 1) tmp = a[b]; ). There is also the
> +problem of a compiler reloading b after having loaded a[b], thus having a newer
> +copy of b than a[b]. A consensus has not yet been reached about these problems,
> +however the ACCESS_ONCE macro is a good place to start looking.
Please add something like:
"For example, b_local = b; smp_read_barrier_depends(); tmp = a[b_local];"
> SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
> systems because it is assumed that a CPU will appear to be self-consistent,
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
