[ltt-dev] [PATCH v2] cmm: provide lightweight smp_rmb/smp_wmb on PPC

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

* Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> On Thu, Sep 22, 2011 at 10:42:52AM +0200, Paolo Bonzini wrote:
> > lwsync orders loads in cacheable memory with respect to other loads,
> > and stores in cacheable memory with respect to other stores.  Use it
> > to implement smp_rmb/smp_wmb.
> > 
> > The heavy-weight sync is still used for the "full" rmb/wmb operations,
> > as well as for smp_mb.
> > 
> > Signed-off-by: Paolo Bonzini <pbonzini at redhat.com>
> > ---
> >  urcu/arch/ppc.h |   10 +++++++++-
> >  1 files changed, 9 insertions(+), 1 deletions(-)
> > 
> > diff --git a/urcu/arch/ppc.h b/urcu/arch/ppc.h
> > index a03d688..05f7db6 100644
> > --- a/urcu/arch/ppc.h
> > +++ b/urcu/arch/ppc.h
> > @@ -32,7 +32,15 @@ extern "C" {
> >  /* Include size of POWER5+ L3 cache lines: 256 bytes */
> >  #define CAA_CACHE_LINE_SIZE	256
> > 
> > -#define cmm_mb()    asm volatile("sync":::"memory")
> > +#define cmm_mb()         asm volatile("sync":::"memory")
> > +
> > +/* lwsync does not preserve ordering of cacheable vs. non-cacheable
> > + * accesses, but it is good when MMIO is not in use.  An eieio+lwsync
> > + * pair is also not enough for rmb, because it will order cacheable
> > + * and non-cacheable memory operations separately---i.e. not the latter
> > + * against the former.  */
> > +#define cmm_smp_rmb()    asm volatile("lwsync":::"memory")
> > +#define cmm_smp_wmb()    asm volatile("lwsync":::"memory")
> 
> This works for recent Power hardware, and I see no reason to care about
> stuff old enough to lack lwsync.  I must defer to others on embedded
> PowerPC.

commit e62b2f86c5ec06ed41d33ed578e66fad426ff215
Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
Date:   Thu Sep 22 11:00:14 2011 -0400

    powerpc: use __NO_LWSYNC__ check to use appropriate lwsync/sync opcode
    
    We already used it in uatomic code, move it to arch ppc.
    
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>

it's fixed now ;)

Thanks,

Mathieu


> 
> 							Thanx, Paul
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com