Linus Torvalds writes: > In general, I'd *much* rather we used barriers. Anything that "depends" on > volatile is pretty much set up to be buggy. But I'm certainly also willing > to have that volatile inside "atomic_read/atomic_set()" if it avoids code > that would otherwise break - ie if it hides a bug.
The cost of doing so seems to me to be well down in the noise - 44 bytes of extra kernel text on a ppc64 G5 config, and I don't believe the extra few cycles for the occasional extra load would be measurable (they should all hit in the L1 dcache). I don't mind if x86[-64] have atomic_read/set be nonvolatile and find all the missing barriers, but for now on powerpc, I think that not having to find those missing barriers is worth the 0.00076% increase in kernel text size. Paul. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
