On Sat, Apr 23, 2016 at 04:37:36AM +0200, Peter Zijlstra wrote: > On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()? > > This barrier is designed to provide an ACQUIRE ordering when combining a > > cmpwait() . > > That's a horrible name for a barrier :-) >
Indeed, and having another special barrier is a pain.
> > And cmpwait() only has minimal ordering guarantee, but if it is actually
> > an ACQUIRE, then the corresponding smp_acquire_barrier__after_cmpwait()
> > is just empty.
> >
> > We might need this special barrier on ppc, because we can implement it
> > with "isync" given that cmpwait() has control dependency and ctrl+isync
> > is ACQUIRE on ppc.
> >
> > Thoughts?
>
> Provide a PPC specific smp_cond_load_acquire() using ISYNC ?
That works, but I should do more investigation on that, I brought this
up because ISYNC may be better than smp_rmb() in two cases, IIUC:
1. for old systems without LWSYNC, smp_rmb() is actually SYNC,
which is heavier than ISYNC.
2. for new systems, isync may be a little faster than lwsync,
according to Michael Ellerman:
http://lkml.kernel.org/g/1437012028.28475.2.ca...@ellerman.id.au
but I doubt these two cases will have any observed performance impact,
so the current version of smp_cond_load_acquire() in your patch is fine,
and we can switch to a specific one in the future we want to ;-)
Regards,
Boqun
signature.asc
Description: PGP signature
