linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Higdon <jeremy@sgi.com>
To: Jes Sorensen <jes@sgi.com>
Cc: Roland Dreier <rdreier@cisco.com>,
	"Bryan O'Sullivan" <bos@pathscale.com>,
	Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] Define wc_wmb, a write barrier for PCI write combining
Date: Wed, 1 Mar 2006 00:24:05 -0800	[thread overview]
Message-ID: <20060301082405.GB289233@sgi.com> (raw)
In-Reply-To: <44048660.3010701@sgi.com>

On Tue, Feb 28, 2006 at 06:20:32PM +0100, Jes Sorensen wrote:
> Roland Dreier wrote:
> >    Jes> Not quite correct as far as I understand it. mmiowb() is
> >    Jes> supposed to guarantee that writes to MMIO space have
> >    Jes> completed before continuing.  That of course covers the
> >    Jes> multi-CPU case, but it should also cover the write-combining
> >    Jes> case.
> >
> >I don't believe this is correct.  mmiowb() does not guarantee that
> >writes have completed -- they may still be pending in a buffer in a
> >bridge somewhere.  The _only_ effect of mmiowb() is to make sure that
> >writes which have been ordered between CPUs using some other mechanism
> >(i.e. a lock) are properly ordered by the rest of the system.  This
> >only has an effect systems like very large ia64 systems, where (as I
> >understand it), writes can pass each other on the way to the PCI bus.
> >In fact, mmiowb() is a NOP on essentially every architecture.
> 
> Hmmmm
> 
> That could be, seems like Jesse agrees that it could all be in the
> pipeline somewhere. Considering Jesse was responsible for mmiowb() I'll
> take his word for it ;-)
> 
> In any case, I'd strongly recommend that any new barrier version is
> clearly documented. The jungle is very dense already ;(


I wonder if wc_wmb() is the best name.

mmiowb expands to memory-mapped I/O write barrier which more or less
describes what it does, whereas wc_wmb expands (I'm guessing) to
write-combine write memory barrier.  But it's for mmio writes.

Also, the wmb() does not actually "guarantee that PCI writes have been
flushed to the bus", at least on IA64.  Even for memory transactions,
it only guarantees ordering on IA64, much like mmiowb does for mmio
transactions.

jeremy

  parent reply	other threads:[~2006-03-01  8:24 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-25  4:20 [PATCH] Define wc_wmb, a write barrier for PCI write combining Bryan O'Sullivan
2006-02-25  4:43 ` Andi Kleen
2006-02-25  7:34   ` Bryan O'Sullivan
2006-02-25 13:28     ` Andi Kleen
2006-02-25 17:20       ` Bryan O'Sullivan
2006-02-25 19:01       ` Bryan O'Sullivan
2006-02-28 17:44         ` Jesse Barnes
2006-02-28 17:50           ` Roland Dreier
2006-02-28 17:50           ` Jesse Barnes
2006-02-28 17:52           ` Bryan O'Sullivan
2006-02-28 17:59             ` Jesse Barnes
2006-02-25 14:28 ` Benjamin LaHaise
2006-02-25 17:11   ` Bryan O'Sullivan
2006-02-25 17:41     ` Benjamin LaHaise
2006-02-28 17:50       ` Bryan O'Sullivan
2006-02-28 17:58         ` Benjamin LaHaise
2006-02-28 18:20           ` Bryan O'Sullivan
2006-02-28 19:03             ` Benjamin LaHaise
2006-02-28 19:20               ` Bryan O'Sullivan
2006-02-28 19:33                 ` Andi Kleen
2006-02-28 19:44                   ` Bryan O'Sullivan
2006-03-01 19:20                   ` Bryan O'Sullivan
2006-03-01 19:27                     ` Andi Kleen
2006-03-01 19:43                       ` Bryan O'Sullivan
2006-03-01 19:49                         ` Andi Kleen
2006-03-01 20:05                           ` Bryan O'Sullivan
2006-03-01 20:26                             ` Benjamin LaHaise
2006-03-01 20:35                               ` Bryan O'Sullivan
2006-02-28 19:34                 ` Benjamin LaHaise
2006-02-28 18:22           ` Christopher Friesen
2006-02-28 10:01 ` Jes Sorensen
2006-02-28 15:42   ` Roland Dreier
2006-02-28 16:08     ` Jes Sorensen
2006-02-28 17:02       ` Roland Dreier
2006-02-28 17:13         ` Jesse Barnes
2006-02-28 17:20         ` Jes Sorensen
2006-03-01  8:16           ` Jeremy Higdon
2006-03-01  8:24           ` Jeremy Higdon [this message]
2006-02-28 17:11       ` Jesse Barnes
2006-02-28 17:57   ` Bryan O'Sullivan
2006-02-28 18:07     ` linux-os (Dick Johnson)
2006-02-28 18:24       ` Christopher Friesen
2006-03-01 10:45     ` Jes Sorensen
2006-03-01 17:04       ` Roland Dreier

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=20060301082405.GB289233@sgi.com \
    --to=jeremy@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=bos@pathscale.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdreier@cisco.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 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).