Messages in this thread | | | Date | Thu, 16 Aug 2007 11:09:25 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH 6/24] make atomic_read() behave consistently on frv |
| |
Paul E. McKenney wrote: > On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
>>Especially since several big architectures don't have volatile in their >>atomic_get and _set, I think it would be a step backwards to add them in >>as a "just in case" thin now (unless there is a better reason). > > > Good point, except that I would expect gcc's optimization to continue > to improve. I would like the kernel to be able to take advantage of > improved optimization, which means that we are going to have to make > a few changes. Adding volatile to atomic_get() and atomic_set() is > IMHO one of those changes.
What optimisations? gcc already does most of the things you need a barrier/volatile for, like reordering non-dependant loads and stores, and eliminating mem ops completely by caching in registers.
>>As to your followup question of why to use it over ACCESS_ONCE. I >>guess, aside from consistency with the rest of the barrier APIs, you >>can use it in other primitives when you don't actually know what the >>caller is going to do or if it even will make an access. You could >>also use it between calls to _other_ primitives, etc... it just >>seems more flexible to me, but I haven't actually used such a thing >>in real code... >> >>ACCESS_ONCE doesn't seem as descriptive. What it results in is the >>memory location being loaded or stored (presumably once exactly), >>but I think the more general underlying idea is a barrier point. > > > OK, first, I am not arguing that ACCESS_ONCE() can replace all current > uses of barrier().
OK. Well I also wasn't saying that ACCESS_ONCE should not be implemented. But if we want something like it, then it would make sense to have an equivalent barrier statement as well (ie. order()).
-- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |