LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Howells <dhowells@redhat.com>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>,
	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,
	paulmck@us.ibm.com
Subject: Re: I/O memory barriers vs SMP memory barriers
Date: Sun, 25 Mar 2007 06:16:27 +1000	[thread overview]
Message-ID: <1174767387.10836.107.camel@localhost.localdomain> (raw)
In-Reply-To: <16051.1174657433@redhat.com>

On Fri, 2007-03-23 at 13:43 +0000, David Howells wrote:
> [Resend - this time with a comma in the addresses, not a dot]
> 
> Lennert Buytenhek <buytenh@wantstofly.org> 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...
> 
> I see your problem.  I think the right way to deal with this is to get rid of
> mb(), rmb(), wmb() and read_barrier_depends() and replace them with io_mb(),
> io_rmb(), ...

Hrm... I'm not sure I like the io_* name, I think it's even more
confusing, people will never know when to use what ...

Maybe we should dig out again my attempt at properly defining semantics
of IO accessors and related barriers and extend it to include CPU vs.
DMA barriers.

Ben.



  parent reply	other threads:[~2007-03-24 20:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070323111350.GD3980@xi.wantstofly.org>
     [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>
2007-03-23 13:43           ` David Howells
2007-03-23 15:08             ` Lennert Buytenhek
2007-03-24 20:16             ` Benjamin Herrenschmidt [this message]
2007-03-25 21:15             ` Paul E. McKenney
2007-03-25 21:38               ` Lennert Buytenhek
2007-03-26  3:24                 ` Paul E. McKenney
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
2007-03-26 10:07             ` 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=1174767387.10836.107.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --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=paulmck@us.ibm.com \
    --cc=torvalds@osdl.org \
    --subject='Re: I/O memory barriers vs SMP memory barriers' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).