Russell King - ARM Linux wrote: > > By the way, I see ARM defines cpu_relax as smp_mb() on arch >= 6. Is > > that correct and useful? On other architectures*, barrier() is enough > > of a barrier, but it's conceivable that smp_mb() would have some > > ARM-specific fairness or bus activity benefit - in which case it > > should probably be mb(). > > See a discussion last year with Linus. It's there to ensure that one CPU > spinning on a variable can see a write by another CPU to that same > variable. Without the barrier, the visibility effects are unbounded on > ARMv6 - and it's only like that for ARMv6, not >= ARMv6. Ah, thanks. It might be relevant to this thread; I'm not sure. 'git show 534be1d5' explains how it works: cpu_relax() flushes buffered writes from _this_ CPU, so that other CPUs which are polling can make progress, which avoids this CPU getting stuck if there is an indirect dependency (no matter how convoluted) between what it's polling and which it wrote just before. So cpu_relax() is *essential* in some polling loops, not a hint. In principle that could happen for I/O polling, if (a) buffered memory writes are delayed by I/O read transactions, and (b) the device state we're waiting on depends on I/O yet to be done on another CPU, which could be polling memory first (e.g. a spinlock). I doubt (a) in practice - but what about buses that block during I/O read? (I have a chip like that here, but it's ARMv4T.) If so, readl() doesn't have a barrier that addresses the issue. (b) is conceivable, and if the memory is a spinlock, spin_unlock() does _not_ deal with this on ARMv6, as it has no barrier after the write. ('git show c5113b61' doesn't really explain why.) It's convoluted and unlikely, but (imho) suggests cpu_relax() is good practice in polling loops, even if not needed. It doesn't cost anything. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html