Re: smp_store_mb() oddity..

2015-07-02 Thread Benjamin Herrenschmidt
On Wed, 2015-07-01 at 19:17 +0200, Peter Zijlstra wrote: > Subject: locking/arch: Make smp_store_mb() use smp_mb() > > Linus noticed that there were a few smp_store_mb() implementations that > used mb(), which is inconsistent with the new naming. > > Since all smp_store_mb() users really are abo

Re: smp_store_mb() oddity..

2015-07-01 Thread Heiko Carstens
On Wed, Jul 01, 2015 at 07:17:55PM +0200, Peter Zijlstra wrote: > --- > Subject: locking/arch: Make smp_store_mb() use smp_mb() > > Linus noticed that there were a few smp_store_mb() implementations that > used mb(), which is inconsistent with the new naming. > > Since all smp_store_mb() users re

Re: smp_store_mb() oddity..

2015-07-01 Thread Peter Zijlstra
On Wed, Jul 01, 2015 at 09:39:44AM -0700, Linus Torvalds wrote: > Peter/Ingo, > while resolving a conflict, I noticed that we have the generic > default definition of "smp_store_mb()" be: > > do { WRITE_ONCE(var, value); mb(); } while (0) > > which looks pretty odd. Why? That "mb()" is a fu

smp_store_mb() oddity..

2015-07-01 Thread Linus Torvalds
Peter/Ingo, while resolving a conflict, I noticed that we have the generic default definition of "smp_store_mb()" be: do { WRITE_ONCE(var, value); mb(); } while (0) which looks pretty odd. Why? That "mb()" is a full memory barrier even on UP, yet this is clearly a smp barrier. So I think t