Synchronization [was Re: The Magic Show: kernel_map() disappearing]
Jes Sorensen
Jes.Sorensen at cern.ch
Fri Jan 15 19:40:13 EST 1999
>>>>> "Paul" == Paul Mackerras <paulus at cs.anu.edu.au> writes:
Paul> Alan Cox <alan at 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 at lists.linuxppc.org ]]
More information about the Linuxppc-dev
mailing list