public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jesse.barnes@intel.com>
To: "Dr. David Alan Gilbert" <linux@treblig.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Intel Memory Ordering White Paper
Date: Wed, 19 Sep 2007 09:26:54 -0700	[thread overview]
Message-ID: <200709190926.55200.jesse.barnes@intel.com> (raw)
In-Reply-To: <20070912182622.GA16520@gallifrey>

On Wednesday, September 12, 2007 11:26 am Dr. David Alan Gilbert wrote:
> * Jesse Barnes (jesse.barnes@intel.com) wrote:
> > FYI, we just released a new white paper describing memory ordering
> > for Intel processors:
> > http://developer.intel.com/products/processor/manuals/index.htm
> >
> > Should help answer some questions about some of the ordering
> > primitives we use on i386 and x86_64.
>
> Hi Jesse,
>   Thanks for letting everyone know about that paper, however - it
> has confused me somewhat; there seem to be differences in that
> description and that described in the 'Intel 64 and IA-32
> Architectures Software Developer's Manual' and I'd like to understand
> whether this paper is designed just to explain points or is actually
> intended to change what can be expected of the processor.
>
> That ordering doc states:
> 'Loads are not reordered with other loads'
>
> Vol3a section 7.2.1 of the architecture manual states:
>
> 'Reads can be carried out speculatively and in any order.'
>
> Is this a:
>   1) Change in the definition of the architecture that existing
> processors actually follow anyway.
>   2) A difference between what the processor does and what is visible
> to the software (the intro to this paper does seem to emphasize
> software visibility more than the architecture manual).
>   3) Some other difference I haven't spotted.

It's really both (1) and (2).  This document will become part of the 
regular manuals when the next version is published.  And yes, 
processors may do something different internally, but software can rely 
on the behavior described by the rules in the document.

Jesse

  reply	other threads:[~2007-09-19 16:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-07 22:26 Intel Memory Ordering White Paper Jesse Barnes
2007-09-08  8:54 ` Nick Piggin
2007-09-07 23:20   ` Linus Torvalds
2007-09-08 17:34     ` Nick Piggin
2007-09-08 17:48       ` Nick Piggin
2007-09-07 18:13         ` Nick Piggin
2007-09-08  8:53           ` Andi Kleen
2007-09-07 19:57             ` Nick Piggin
2007-09-08 10:19               ` Andi Kleen
2007-09-07 20:32                 ` Nick Piggin
2007-09-08 20:37                   ` H. Peter Anvin
2007-09-08 11:34         ` dean gaudet
2007-09-08 12:08           ` Petr Vandrovec
2007-09-08 12:27             ` dean gaudet
2007-09-08 10:30   ` Alan Cox
2007-09-07 20:46     ` Nick Piggin
2007-09-08 10:29 ` Alan Cox
2007-09-07 20:49   ` Nick Piggin
2007-09-08 14:11     ` Alan Cox
2007-09-12 18:26 ` Dr. David Alan Gilbert
2007-09-19 16:26   ` Jesse Barnes [this message]
2007-09-19 17:29     ` Andi Kleen

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=200709190926.55200.jesse.barnes@intel.com \
    --to=jesse.barnes@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@treblig.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