On Sun, Mar 25, 2007 at 02:15:42PM -0700, Paul E. McKenney wrote: > > > [ background: On ARM, SMP synchronisation does need barriers but device > > > synchronisation does not. The question is that given this, whether > > > mb() and friends can be NOPs on ARM or not (i.e. whether mb() is > > > supposed to sync against other CPUs or not, or whether only smp_mb() > > > can be used for this.) ] > > > > Hmmmm... > > > > [snip] > > 3. Orders memory accesses and device accesses, but not necessarily > the union of the two -- mb(), rmb(), wmb().
If mb/rmb/wmb are required to order normal memory accesses, that means that the change made in commit 9623b3732d11b0a18d9af3419f680d27ea24b014 to always define mb/rmb/wmb as barrier() on ARM systems was wrong. Does everybody agree on these semantics, though? At least David seems to think that mb/rmb/wmb aren't required to order normal memory accesses against each other.. > 4. Orders only device accesses, which is what seems to be looked > for here. Yes. (As above, on ARM, SMP synchronisation does need barriers but device synchronisation does not. If mb/rmb/wmb were only required to synchronise device accesses, they could have been regular compiler barriers on ARM, but if they are also required to synchronise normal memory accesses against each other, they have to map to hardware barriers.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
