mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Bryan O'Sullivan" <bos@pathscale.com>
To: Andi Kleen <ak@suse.de>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
	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 12:05:07 -0800	[thread overview]
Message-ID: <1141243508.2899.126.camel@localhost.localdomain> (raw)
In-Reply-To: <200603012049.32670.ak@suse.de>

On Wed, 2006-03-01 at 20:49 +0100, Andi Kleen wrote:

> Relying on undocumented side effects of instructions as you're trying
> to do here is not very reliable and would likely cause breakage later.

I just quoted you the precise relevant semantics of sfence two messages
earlier, from the AMD64 optimisation guide.  Here's the same thing from
the EM64T optimisation guide.  See page 444 of the following PDF:

        ftp://download.intel.com/design/Pentium4/manuals/25366818.pdf

Here's the relevant quote:

        Writes may be delayed and combined in the write combining buffer
        (WC buffer) to reduce memory accesses. If the WC buffer is
        partially filled, the writes may be delayed until the next
        occurrence of a serializing event; such as, an SFENCE or MFENCE
        instruction, [...]
        
If you read section 10.3.1 of the same document (page 446), you'll see
that a CLFLUSH (as you suggested earlier) won't even work to get the WC
buffers to flush, because they're not part of the regular cache
hierarchy.

This section also makes it clear yet again that wmb() is absolutely not
sufficient to get program store order semantics in the presence of WC;
you *have* to use an explicit synchronising instruction of some kind.

This is pretty frustrating.  I'm quoting the manufacturer documentation
at you, and you're handwaving back at me with complete nonsense.

	<b


  reply	other threads:[~2006-03-01 20:04 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-25  4:20 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 [this message]
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=1141243508.2899.126.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

Powered by JetHome