On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote: > > If they're not doing anything, sure. Plenty of loops actually do some sort > of real work while waiting for their halt condition, possibly even work > which is necessary for their halt condition to occur, and you definitely > don't want to be doing cpu_relax() in this case. On register-rich > architectures you can do quite a lot of work without needing to reuse the > register containing the result of the atomic_read(). Those are precisely > the architectures where barrier() hurts the most.
I have a problem with this argument. The same loop could be using a non-atomic as long as the updaters are serialised. Would you suggest that we turn such non-atomics into volatiles too? Any loop that's waiting for an external halt condition either has to schedule away (which is a barrier) or you'd be busy waiting in which case you should use cpu_relax. Do you have an example where this isn't the case? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - 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
