Re: [PATCH 6/24] make atomic_read() behave consistently on frv

[Nick Piggin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/