From: David Mosberger <davidm@napali.hpl.hp.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: davidm@hpl.hp.com, torvalds@transmeta.com, engebret@vnet.ibm.com,
justincarlson@cmu.edu, alan@lxorguk.ukuu.org.uk,
linux-kernel@vger.kernel.org, anton@samba.org, ak@suse.de,
paulus@samba.org
Subject: Re: Memory Barrier Definitions
Date: Mon, 13 May 2002 09:36:29 -0700 [thread overview]
Message-ID: <15583.60301.410541.204804@napali.hpl.hp.com> (raw)
In-Reply-To: <20020513132605.06b44d85.rusty@rustcorp.com.au>
>>>>> On Mon, 13 May 2002 13:26:05 +1000, Rusty Russell <rusty@rustcorp.com.au> said:
Rusty> OK. So ignoring the fact that you somehow have to attach
Rusty> your barriers to a load or store for the moment, we have
Rusty> before vs. after (ia64), read vs. write (most archs), io vs
Rusty> mem (ppc, ppc64), data dependency vs non-data dependency
Rusty> (alpha), and smp vs up.
An alternative way to think about the ia64 model is that it provides
"ordering" variables. Accesses to those variables won't be reordered
by the compiler or the CPU and also order other (normally unordered
accesses). One way to support this is have an ORDERING attribute for
variables (which would expand into "volatile" on ia64). This would
have to be complemented by a set of barrier routines which will
achieve the desired ordering on machines that don't have the
acquire/release model of ia64 (and on ia64, they would expand into
nothing).
--david
next prev parent reply other threads:[~2002-05-13 16:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-07 19:07 Dave Engebretsen
2002-05-07 19:49 ` Alan Cox
2002-05-07 19:53 ` Dave Engebretsen
2002-05-07 20:27 ` Alan Cox
2002-05-07 21:23 ` Dave Engebretsen
2002-05-07 22:15 ` justincarlson
2002-05-08 2:49 ` Dave Engebretsen
2002-05-08 13:54 ` Justin Carlson
2002-05-08 15:27 ` Dave Engebretsen
2002-05-08 15:49 ` Andi Kleen
2002-05-08 17:07 ` David Mosberger
2002-05-09 7:36 ` Rusty Russell
2002-05-09 8:01 ` Keith Owens
2002-05-09 15:00 ` David Mosberger
2002-05-13 3:26 ` Rusty Russell
2002-05-13 16:36 ` David Mosberger [this message]
2002-05-13 16:50 ` Linus Torvalds
2002-05-13 17:53 ` David Mosberger
2002-05-13 23:28 ` Rusty Russell
2002-05-07 22:57 ` Anton Blanchard
2002-05-13 18:16 ` Jesse Barnes
2002-05-09 11:33 Manfred Spraul
2002-05-09 19:38 ` Dave Engebretsen
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=15583.60301.410541.204804@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=ak@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=anton@samba.org \
--cc=davidm@hpl.hp.com \
--cc=engebret@vnet.ibm.com \
--cc=justincarlson@cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@transmeta.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
all inboxes | Powered by JetHome®