From: Dave Engebretsen <engebret@vnet.ibm.com>
To: justincarlson@cmu.edu
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: Memory Barrier Definitions
Date: Tue, 07 May 2002 21:49:43 -0500 [thread overview]
Message-ID: <3CD89247.8ECB01A4@vnet.ibm.com> (raw)
In-Reply-To: <E175BY8-0008S4-00@the-village.bc.nu> <1020809750.13627.24.camel@gs256.sp.cs.cmu.edu>
justincarlson@cmu.edu wrote:
>
> On Tue, 2002-05-07 at 16:27, Alan Cox wrote:
> > and our current heirarchy is a little bit more squashed than that. I'd
> > agree. We actually hit a corner case of this on the IDT winchip x86 where
> > we run relaxed store ordering and have to define wmb() as a locked add of
> > zero to the top of stack - which does have a penalty that isnt needed
> > for CPU ordering.
> >
> > How much of this impacts Mips64 ?
>
> In terms of the MIPS{32|64} ISA, the current primitives seem fine;
> there's only 1 option defined in the ISA: 'sync'. Order for all
> off-cache accesses is guaranteed around a sync.
>
> It gets a bit more complicated when you talk about what particular
> implementations do, and ordering rules for uncached vs cached accesses,
> but to the best of my knowledge there aren't any fundamental problems as
> described for the PPC.
>
> -Justin
PPC also guarantees every ordering when using the 'sync' instruction, so
that will give correctness at the price of a 1000 cycles or so. You
refer to different rules for cached vs uncached on other implementations
-- that is the essence of our problem. Are there different barrier
instructions in MIPS which provide different levels of performance for
different ordering enforcements?
Dave.
next prev parent reply other threads:[~2002-05-08 2:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-07 19:07 Memory Barrier Definitions 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 [this message]
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
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
-- strict thread matches above, loose matches on Subject: below --
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=3CD89247.8ECB01A4@vnet.ibm.com \
--to=engebret@vnet.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=justincarlson@cmu.edu \
--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