mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: justincarlson@cmu.edu
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dave Engebretsen <engebret@vnet.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: Memory Barrier Definitions
Date: 07 May 2002 18:15:50 -0400	[thread overview]
Message-ID: <1020809750.13627.24.camel@gs256.sp.cs.cmu.edu> (raw)
In-Reply-To: <E175BY8-0008S4-00@the-village.bc.nu>

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

  parent reply	other threads:[~2002-05-07 22:16 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 [this message]
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
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=1020809750.13627.24.camel@gs256.sp.cs.cmu.edu \
    --to=justincarlson@cmu.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=engebret@vnet.ibm.com \
    --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

all inboxes | Powered by JetHome®