All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: David Howells <dhowells@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	ARM Linux Mailing List  <linux-arm-kernel@lists.arm.linux.org.uk>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: I/O memory barriers vs SMP memory barriers
Date: Sun, 25 Mar 2007 20:24:18 -0700	[thread overview]
Message-ID: <20070326032418.GA14557@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070325213843.GE22126@xi.wantstofly.org>

On Sun, Mar 25, 2007 at 11:38:43PM +0200, Lennert Buytenhek wrote:
> On Sun, Mar 25, 2007 at 02:15:42PM -0700, Paul E. McKenney wrote:
> 
> > > > [ background: On ARM, SMP synchronisation does need barriers but device
> > > >   synchronisation does not.  The question is that given this, whether
> > > >   mb() and friends can be NOPs on ARM or not (i.e. whether mb() is
> > > >   supposed to sync against other CPUs or not, or whether only smp_mb()
> > > >   can be used for this.)  ]
> > > 
> > > Hmmmm...
> > > 
> > > [snip]
> > 
> > 3.	Orders memory accesses and device accesses, but not necessarily
> > 	the union of the two -- mb(), rmb(), wmb().
> 
> If mb/rmb/wmb are required to order normal memory accesses, that means
> that the change made in commit 9623b3732d11b0a18d9af3419f680d27ea24b014
> to always define mb/rmb/wmb as barrier() on ARM systems was wrong.

This was on UP ARM systems, right?  Assuming that ARM CPUs respect the
usual CPU-self-consistency semantics, and given the background that
device accesses are ordered, then it might well be OK to have mb/rmb/wmb
be barrier() on UP ARM systems.

Most likely not on SMP ARM systems, however.

> Does everybody agree on these semantics, though?  At least David seems
> to think that mb/rmb/wmb aren't required to order normal memory accesses
> against each other..

Not on UP.  On SMP, ordering is (almost certainly) required.

> > 4.	Orders only device accesses, which is what seems to be looked
> > 	for here.
> 
> Yes.  (As above, on ARM, SMP synchronisation does need barriers but
> device synchronisation does not.  If mb/rmb/wmb were only required to
> synchronise device accesses, they could have been regular compiler
> barriers on ARM, but if they are also required to synchronise normal
> memory accesses against each other, they have to map to hardware
> barriers.)

Again, for kernels built for UP, you might well be able to make the
mb() primitives be barrier().  I don't see it for SMP, though.

						Thanx, Paul

  reply	other threads:[~2007-03-26  3:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <e9c3a7c20703021312y5f7aa228i5d1c84a8e9ea5676@mail.gmail.com>
     [not found] ` <20070303111427.GB16944@xi.wantstofly.org>
     [not found]   ` <20070303113305.GB10515@flint.arm.linux.org.uk>
     [not found]     ` <20070321221134.GA22497@xi.wantstofly.org>
     [not found]       ` <tnxlkhpgslz.fsf@arm.com>
     [not found]         ` <20070323111350.GD3980@xi.wantstofly.org>
2007-03-23 13:43           ` I/O memory barriers vs SMP memory barriers David Howells
2007-03-23 15:08             ` Lennert Buytenhek
2007-03-24 20:16             ` Benjamin Herrenschmidt
2007-03-26 10:07               ` David Howells
2007-03-25 21:15             ` Paul E. McKenney
2007-03-25 21:38               ` Lennert Buytenhek
2007-03-26  3:24                 ` Paul E. McKenney [this message]
2007-03-26  8:46                   ` Lennert Buytenhek
2007-03-26 20:07                     ` Paul E. McKenney
2007-03-28 18:36                       ` Lennert Buytenhek
2007-03-26 10:04                 ` David Howells

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=20070326032418.GA14557@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=buytenh@wantstofly.org \
    --cc=catalin.marinas@arm.com \
    --cc=dan.j.williams@intel.com \
    --cc=dhowells@redhat.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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.