linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: "Bryan O'Sullivan" <bos@pathscale.com>
Cc: Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Define wc_wmb, a write barrier for PCI write combining
Date: Tue, 28 Feb 2006 14:03:54 -0500	[thread overview]
Message-ID: <20060228190354.GE24306@kvack.org> (raw)
In-Reply-To: <1141150814.24103.37.camel@camp4.serpentine.com>

On Tue, Feb 28, 2006 at 10:20:14AM -0800, Bryan O'Sullivan wrote:
> No.  We're writing to a region that we've marked as write combining, so
> the processor or north bridge will not write in program order.  It's
> free to write out the write combining store buffers in whatever order it
> feels like, unless forced to do otherwise.

The rules are a bit more complex than that -- write are weakly ordered, 
but still ordered.  They maybe be delayed with respect to other stores, 
but will never occur before other stores are visible to the cache 
heirarchy.  In terms of how writes to the write combining region are 
delayed, you'll have to look at the addresses of the registers you are 
writing to.  If they map to the same write combining buffer (that is each 
one can combine with the previous write) and are increasing in address, 
then you don't need the explicite barrier.  Most hardware is laid out so 
that this is possible.

The case the write combining buffers affect memory ordering in an 'unexpected' 
way is if your writes combine and you write to registers in an order that 
is opposite from that in which they combine.  Ie, a write to address 8 
followed by a write to address 0 that combines will show up on the bus 
as 0, 8 (assuming an 8 byte writes at 0).  Besides that, the write combining 
buffers can introduce a delay of a few clocks while the cpu defers the write 
in the hope that it will combine with another write, but that delay applies 
to all writes that go through the write combining buffers and thus do not 
change the memory ordering (except as previously noted).

Memory barriers are not cheap.  At least for the example you provided, 
it looks like things are overdone and performance is going to suck, so 
it needs to be avoided if at all possible.  I really think that you 
should be using wmb().

		-ben
-- 
"Ladies and gentlemen, I'm sorry to interrupt, but the police are here 
and they've asked us to stop the party."  Don't Email: <dont@kvack.org>.

  reply	other threads:[~2006-02-28 19:08 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 [this message]
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
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=20060228190354.GE24306@kvack.org \
    --to=bcrl@kvack.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=bos@pathscale.com \
    --cc=linux-kernel@vger.kernel.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 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).