public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Bryan O'Sullivan" <bos@pathscale.com>
To: Andi Kleen <ak@suse.de>, Benjamin LaHaise <bcrl@kvack.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Define wc_wmb, a write barrier for PCI write combining
Date: Wed, 01 Mar 2006 11:20:23 -0800	[thread overview]
Message-ID: <1141240823.2899.84.camel@localhost.localdomain> (raw)
In-Reply-To: <200602282033.48570.ak@suse.de>

On Tue, 2006-02-28 at 20:33 +0100, Andi Kleen wrote:

> Anyways if MFENCE improved performance you're probably relying
> on some very specific artifact of the microarchitecture of your 
> CPU or Northbridge. I don't think it's a architecurally guaranteed
> feature.

I looked this up, and you appear to be wrong here.

Here's the appropriate quote from page 246 of the PDF of "AMD64
Architecture Programmer's Manual Volume 2: System Programming":

        http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_24593.pdf

Section 7.4.1 specifically describes what happens to write buffers:

        [...] the processor completely empties the write buffer by
        writing the contents to memory as a result of performing any of
        the following operations:
        
        SFENCE Instruction
        Executing a store-fence (SFENCE) instruction forces all memory
        writes before the SFENCE (in program order) to be written into
        memory before memory writes that follow the SFENCE instruction.
        The memory-fence (MFENCE) instruction has a similar effect, but
        it forces the ordering of loads in addition to stores.
        [...]

So in fact SFENCE is the appropriate, architecturally guaranteed, thing
for us to be doing on x86_64.

With respect to Ben's contention that wmb() will suffice instead, that
isn't true, either, even on x86-class hardware.  The writes absolutely
travel over the HT bus in non-ascending order on AMD64 systems unless we
fence them, and we've verified this using a HT bus analyser.

	<b


  parent reply	other threads:[~2006-03-01 19:20 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 [this message]
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=1141240823.2899.84.camel@localhost.localdomain \
    --to=bos@pathscale.com \
    --cc=ak@suse.de \
    --cc=bcrl@kvack.org \
    --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