[parisc-linux-cvs] linux-2.6 jejb

Grant Grundler grundler at parisc-linux.org
Fri Aug 20 01:20:02 MDT 2004


On Wed, Aug 18, 2004 at 10:12:55AM -0400, James Bottomley wrote:
> It's not a gcc *memory* barrier.
> That means gcc is free to load a
> memory reference before the spin lock and then use it after.

Wait...what you just described sounds like the toolchain was reordering
instructions (which happen to access memory). memory barrier to
me means we tell both HW to not re-order in certain ways (eg acquire,
release semantics for ia64) *AND* we tell gcc to not re-order
instructions around these memory barriers.

> That's
> what was happening in the f_list case, and why adding mb fixes the
> problem.

ok. At least I'm pretty sure I understand the problem now.

> > mb() is a NOP on parisc because we have strongly ordered memory.
> > 
> > PA20 arch allows weakly ordered mem.
> > John Marvin was clear all implementations are strongly ordered.
> > (See the mail archive for discussion about this)
> 
> Well...I don't think it should be.

The above was a statement of fact: All PARISC CPUs are strongly ordered.
Forget what the PA20 arch says.

> If we're going to keep the O bit zero then our mb() should be

It's too late...I'll look up what O-bit does tomorrow... :^(

> asm volatile("sync" : : : "memory");

I think we really only need the "memory" reference.
If we can just add that to the spinlock implementation or mb()
implementation, I expect that should be sufficient.
Maybe someone more fluent in parisc asm could correct/confirm?

> because it will then be semantically correct should a weakly ordered
> processor ever come along.

This will never happen. I'm 100% certain of that.
PA-RISC/HPUX would need rework that HP is not willing to invest.

>   For a strongly ordered processor, this is
> almost a nop anyway...

I don't think so.
ISTR V-class folks describe dmasync as a "system deep heave".
I don't know if sync has the same impact.
dmasync did not have near as much impact on smaller ccio/sba DMA systems.
But perf folks worked hard to structure things so sync/dmasync were mostly
avoided.  (ie those folks thought it was expensive). If someone can
quantify the impact of sync and dmasync on some platforms of interest
(eg Astro, ZX1, Stretch, or superdome), I would be very grateful.

thanks,
grant


More information about the parisc-linux-cvs mailing list