Re: [parisc-linux] coherent ops and mb() revisited

[Grant Grundler <grundler@parisc-linux.org>]

On Mon, Sep 06, 2004 at 10:15:29AM -0400, James Bottomley wrote:
> On Mon, 2004-09-06 at 00:19, Grant Grundler wrote:
> > Actaully, I don't think it's irrelevant.  If a lock is contended for,
> > re-ordering by gcc could excerbate the problem by adding additional
> > instructions (good for the instruction pipeline) to the "critical
> > section" (the period we actually hold the lock).
> 
> But that's what placing the mb() after the spinlock code does: confines
> the critical section and prevents gcc reordering around it.

Maybe I'm just confused again. I was thinking gcc could move instructions
between the asm("ldcw") and mb(). And the same thing between
mb() and "lock = 1".

In other words, I'm worried about the "distance" bewteen lock/unlock
ops is greater than the "distance" between two mb() that contain
the critical section of code.

> > This is why I'm asking about use of "memory" in the actual
> > asm instruction that either acquire or release the lock
> > instead of using mb().
> 
> You probably get slightly more confinement by using mb() instead of the
> "memory" clobber in __ldcw().

Erm, how?
Our mb() definition uses asm(:::"memory").
Is that different from using "memory" in the actual bit of assembly?

I just noticed set_eiem(), mtsp() and IRQ support in our system.h
do exactly what I proposed.

> What appeals to me is that the barrier in the spinlocks is explicit.

Yes, me tool.
But I'm suggesting those are superfluous when using "memory" in
the core asm() lock operations.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux