All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Boqun Feng <boqun.feng@gmail.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Anton Blanchard <anton@samba.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation
Date: Wed, 21 Oct 2015 12:34:22 -0700	[thread overview]
Message-ID: <20151021193422.GS5105@linux.vnet.ibm.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CBBD844@AcuExch.aculab.com>

On Wed, Oct 21, 2015 at 04:04:04PM +0000, David Laight wrote:
> From: Paul E. McKenney
> > Sent: 21 October 2015 00:35
> ...
> > There is also the question of whether the barrier forces ordering
> > of unrelated stores, everything initially zero and all accesses
> > READ_ONCE() or WRITE_ONCE():
> > 
> > 	P0		P1		P2		P3
> > 	X = 1;		Y = 1;		r1 = X;		r3 = Y;
> > 					some_barrier();	some_barrier();
> > 					r2 = Y;		r4 = X;
> > 
> > P2's and P3's ordering could be globally visible without requiring
> > P0's and P1's independent stores to be ordered, for example, if you
> > used smp_rmb() for some_barrier().  In contrast, if we used smp_mb()
> > for barrier, everyone would agree on the order of P0's and P0's stores.
> > 
> > There are actually a fair number of different combinations of
> > aspects of memory ordering.  We will need to choose wisely.  ;-)
> 
> My thoughts on this are that most code probably isn't performance critical
> enough to be using anything other than normal locks for inter-cpu
> synchronisation.
> Certainly most people are likely to get it wrong somewhere.
> So you want a big red sticker saying 'Don't try to be too clever'.

I am afraid that I would run out of red stickers rather quickly,
given the large number of ways that one can shoot oneself in the
foot, even when single-threaded.

> Also without examples of why things go wrong (eg member_consumer()
> and alpha) it is difficult to understand the differences between
> all the barriers (etc).

Not just the hardware peculiarities.  It is also important to understand
the common use cases.

> OTOH device driver code may need things slightly stronger than
> barrier() (which I think is asm(:::"memory")) to sequence accesses
> to hardware devices (and memory the hardware reads), but without
> having a strong barrier in every ioread/write() access.

There are more memory models than you can shake a stick at, so yes,
we do have to choose carefully.  And yes, it does get more complex
when you add MMIO, and no, I don't know of any formal model that
takes MMIO into account.

							Thanx, Paul

      reply	other threads:[~2015-10-21 19:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-07 10:59 [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon
2015-10-07 11:19 ` Peter Zijlstra
2015-10-07 13:23   ` Will Deacon
2015-10-07 14:53     ` Peter Zijlstra
2015-10-07 15:25     ` Paul E. McKenney
2015-10-08  3:50       ` Michael Ellerman
2015-10-08 11:16         ` Peter Zijlstra
2015-10-08 12:59           ` Will Deacon
2015-10-08 22:17             ` Paul E. McKenney
2015-10-09  9:51               ` Will Deacon
2015-10-09 11:25                 ` Peter Zijlstra
2015-10-09 17:44                   ` Paul E. McKenney
2015-10-09 17:44                     ` Paul E. McKenney
2015-10-09 17:43                 ` Paul E. McKenney
2015-10-09 18:33                   ` Will Deacon
2015-10-12 23:30                     ` Paul E. McKenney
2015-10-20 14:20                       ` Boqun Feng
2015-10-08 21:44           ` Paul E. McKenney
2015-10-09  7:29             ` Peter Zijlstra
2015-10-09  8:31             ` Peter Zijlstra
2015-10-09  9:40               ` Will Deacon
2015-10-09 11:02                 ` Peter Zijlstra
2015-10-09 12:41                   ` Will Deacon
2015-10-09 11:12                 ` Peter Zijlstra
2015-10-09 12:51                   ` Will Deacon
2015-10-09 13:06                     ` Peter Zijlstra
2015-10-09 11:13                 ` Peter Zijlstra
2015-10-09 17:21                 ` Paul E. McKenney
2015-10-19  1:17                 ` Boqun Feng
2015-10-19 10:23                   ` Peter Zijlstra
2015-10-20  7:35                     ` Boqun Feng
2015-10-20 23:34                   ` Paul E. McKenney
2015-10-21  8:24                     ` Peter Zijlstra
2015-10-21 19:29                       ` Paul E. McKenney
2015-10-21 19:36                         ` Peter Zijlstra
2015-10-21 19:56                           ` Paul E. McKenney
2015-10-21 16:04                     ` David Laight
2015-10-21 16:04                       ` David Laight
2015-10-21 16:04                       ` David Laight
2015-10-21 19:34                       ` Paul E. McKenney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151021193422.GS5105@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=anton@samba.org \
    --cc=boqun.feng@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.