Re: Semantics of smp_mb() [was : Re: [PATCH] Fix RCU race in access of nohz_cpu_mask ]

[Paul E. McKenney]

On Wed, Dec 14, 2005 at 09:27:41AM +1100, Keith Owens wrote:
> On Tue, 13 Dec 2005 08:20:27 -0800, 
> "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> >If the variable p references MMIO rather than normal memory, then
> >wmb() and rmb() are needed instead of smp_wmb() and smp_rmb().
> 
> mmiowb(), not wmb().  IA64 has a different form of memory fence for I/O
> space compared to normal memory.  MIPS also has a non-empty form of
> mmiowb().

New one on me!

> >This is because the I/O device needs to see the accesses ordered
> >even in a UP system.
> 
> Why does mmiowb() map to empty on most systems, including Alpha?
> Should it not map to wmb() for everything except IA64 and MIPS?

Sounds like I am not the only one that it is new to...

There are over four hundred instances of wmb() still in the drivers tree
in 2.6.14.  I suspect that most of them are for MMIO fencing -- the ones
I looked at quickly certainly seem to be.

But, given mmiowb(), what is the point of having wmb()?  Why are
write memory barriers needed in UP kernels if not for MMIO and other
hardware-specific accesses?  Is your thought that use of wmb() should
be phased out in favor of mmiowb()?  (Might be a good idea, but doesn't
look like we are there yet.)

							Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/