Synchronization [was Re: The Magic Show: kernel_map() disappearing]

[luther sven]

On Thu, Jan 14, 1999 at 10:55:37AM +0100, Jes Sorensen wrote:
> >>>>> "Jesper" == Jesper Skov <jskov at cygnus.co.uk> writes:
> 
> >>>>> "Cort" == Cort Dougan <cort at persephone.cs.nmt.edu> writes:
> Cort> You're right, that was an oversight on my part.  I'll fix the
> Cort> mistake.  I'll commit that to vger now.  I'm going to leave the
> Cort> sync in there as well, to make sure that things stall until the
> Cort> writes are done.
> 
> Jesper> OK, core of the problem is that I don't know what mb() is
> Jesper> supposed to do. Here's what we have on the PPC:
> 
> mb() is supposed to ensure that the CPU does not reschedule
> instructions' memory access beyond the mb().
> 
> Jesper>  sync : stall CPU until all IO has completed.  eieio: prevent
> Jesper> CPU from reordering/collapsing reads/writes to memory.  (but
> Jesper> otherwise run at full steam!)
> 
> [snip]
> 
> Jesper> That's why I added the iobarrier() macros (adding _w/_r/_rw on
> Jesper> Alan's request) that are only related to IO synchronization
> Jesper> within the same CPU. Essentially it's just renaming the
> Jesper> eieio() macro already used in many PPC drivers because it's a
> Jesper> bad name; Linux/APUS will be sharing drivers with Linux/m68k
> Jesper> where eieio isn't such a helpful name.
> 
> Jesper> Given that mb() was defined as sync, I assumed mb() to be the
> Jesper> common Linux name for a thingie used for SMP synchronization.
> 
> I guess you would normally use a spinlock() for that, mb() is supposed
> to ensure the ordering regarding access to memory which is really what
> is happening in most of our drivers (at least all the Amiga ones) -
> this is why I was moaning about the iobarrier() stuff as it was not
> clear to me what it was supposed to do differently from mb() - except
> if you want ordering when going out on an I/O bus like on the PC.
> 
> Jesper> I may have been wrong. iobarrier() may not be such a good name
> Jesper> after all, but I think it's important for the names to reflect
> Jesper> the semantics of the function. And there are two separate
> Jesper> synchronization semantics required (at least on the PPC) - I
> Jesper> don't want to merge them just because there's already a common
> Jesper> Linux function that's named mb() (memory barrier, presumably).
> 
> When considering the name, memory barrier is the right name, after
> all, all your driver registers are memory mapped and therefore `just'
> another type of memory.

If i understood things correctly, it shopuld be :

mb() is in fact an eieio call.

spinlock() should be an sync() call.

so the current use of mb() is either wrong or misdefined.

Did i miss something here ?

Friendly;

Sven LUTHER

[[ 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 ]]