public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Jes Sorensen <Jes.Sorensen@cern•ch>
To: Paul.Mackerras@cs•anu.edu.au
Cc: alan@cymru•net, jskov@cygnus•co.uk, cort@persephone•cs.nmt.edu,
	linuxppc-dev@lists•linuxppc.org, linux-apus@sunsite•auc.dk
Subject: Re: Synchronization [was Re: The Magic Show: kernel_map() disappearing]
Date: 15 Jan 1999 09:40:13 +0100	[thread overview]
Message-ID: <d3hftt7wuq.fsf@valhall.cern.ch> (raw)
In-Reply-To: Paul Mackerras's message of "Fri, 15 Jan 1999 12:57:32 +1100"


>>>>> "Paul" == Paul Mackerras <paulus@cs•anu.edu.au> writes:

Paul> Alan Cox <alan@cymru•net> wrote:
>> > eieio: prevent CPU from reordering/collapsing reads/writes to
>> memory.  > (but otherwise run at full steam!)
>> 
>> Thats what mb() does - its a memory-barrier hence the name - it
>> imposes strong store ordering properties across it.

Paul> My understanding of the original mb() (and correct me if I'm
Paul> wrong) was that it basically said "an interrupt or another
Paul> processor might have changed memory, so don't keep values from
Paul> memory cached in registers".  With wmb() on SMP, this seems to
Paul> be extended to include "make sure other cpus can see the values
Paul> we just wrote".  I don't know exactly how rmb() differs from
Paul> mb().

Hmmm

My understanding is that mb() is also meant to ensure that
instructions are issued in the right order, ie. like cases where we
want to read data out of a register in a device before resetting it or
something:

  data = regs->dat;
  mb();
  regs->reset = 1;

Maybe I am missing something, but at least thats the assumption I work
from when I use mb()'s. I haven't noticed wmb()/rmb() and checking the
code I see that these are not defined for the m68k nor the Sparc
ports.

The question is whether it makes sense to introduce the io_barrier()
macros at all or mb() is sufficient as it is. I think it is and I'd
prefer not to try and convince all the other ports to use a new macro
unless we have a real good reason for doing so.  Most cases where you
would use mb() (sync on the PPC) are slow access anyway so as far as I
can see it really doesn't cost that much to let mb() do the sync.

Jes

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists•linuxppc.org ]]

  reply	other threads:[~1999-01-15  8:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <13980.23937.676502.388522@lassi.cygnus.co.uk>
     [not found] ` <Pine.LNX.3.96.990113130000.3632F-100000@persephone.cs.nmt.edu>
1999-01-14  8:57   ` Synchronization [was Re: The Magic Show: kernel_map() disappearing] Jesper Skov
1999-01-14  9:55     ` Jes Sorensen
1999-01-14 16:25       ` luther sven
1999-01-14 13:27     ` Benjamin Herrenschmidt
1999-01-14 19:46     ` Douglas Godfrey
1999-01-14 20:52     ` Alan Cox
1999-01-14 21:53       ` Cort Dougan
1999-01-15  1:38         ` Alan Cox
1999-01-15  8:26         ` Jesper Skov
1999-01-15  1:57       ` Paul Mackerras
1999-01-15  8:40         ` Jes Sorensen [this message]
1999-01-15 16:10         ` Alan Cox
1999-01-15 19:28           ` Cort Dougan
1999-01-16  1:00           ` Douglas Godfrey
1999-01-16  1:09             ` Synchronization [was Re: The Magic Show: kernel_map() Alan Cox
1999-01-15  8:50 Synchronization [was Re: The Magic Show: kernel_map() disappearing] Benjamin Herrenschmidt

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=d3hftt7wuq.fsf@valhall.cern.ch \
    --to=jes.sorensen@cern$(echo .)ch \
    --cc=Paul.Mackerras@cs$(echo .)anu.edu.au \
    --cc=alan@cymru$(echo .)net \
    --cc=cort@persephone$(echo .)cs.nmt.edu \
    --cc=jskov@cygnus$(echo .)co.uk \
    --cc=linux-apus@sunsite$(echo .)auc.dk \
    --cc=linuxppc-dev@lists$(echo .)linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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