On Wed, Feb 10, 2010 at 10:04:06PM +1100, Anton Blanchard wrote: > > For performance reasons we are about to change ISYNC_ON_SMP to sometimes be > lwsync. Now that the macro name doesn't make sense, change it and > LWSYNC_ON_SMP > to better explain what the barriers are doing. > > Signed-off-by: Anton Blanchard <an...@samba.org> > --- > > Index: powerpc.git/arch/powerpc/include/asm/atomic.h > =================================================================== > --- powerpc.git.orig/arch/powerpc/include/asm/atomic.h 2010-02-10 > 17:12:30.264322204 +1100 > +++ powerpc.git/arch/powerpc/include/asm/atomic.h 2010-02-10 > 17:13:05.355571902 +1100 > @@ -49,13 +49,13 @@ static __inline__ int atomic_add_return( > int t; > > __asm__ __volatile__( > - LWSYNC_ON_SMP > + PPC_RELEASE_BARRIER > "1: lwarx %0,0,%2 # atomic_add_return\n\ > add %0,%1,%0\n" > PPC405_ERR77(0,%2) > " stwcx. %0,0,%2 \n\ > bne- 1b" > - ISYNC_ON_SMP > + PPC_ACQUIRE_BARRIER
I wonder if this shouldn't be called PPC_ISYNC_ACQUIRE_BARRIER ? Unlike PPC_RELEASE_BARRIER, it is not an acquire barrier unless it is used like an isync. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev