[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46C3A3C5.5020103@yahoo.com.au>
Date: Thu, 16 Aug 2007 11:09:25 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: paulmck@...ux.vnet.ibm.com
CC: Herbert Xu <herbert@...dor.apana.org.au>, csnook@...hat.com,
dhowells@...hat.com, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, torvalds@...ux-foundation.org,
netdev@...r.kernel.org, akpm@...ux-foundation.org, ak@...e.de,
heiko.carstens@...ibm.com, davem@...emloft.net,
schwidefsky@...ibm.com, wensong@...ux-vs.org, horms@...ge.net.au,
wjiang@...ilience.com, cfriesen@...tel.com, zlynx@....org,
rpjday@...dspring.com, jesper.juhl@...il.com,
Arnd Bergmann <arnd@...db.de>
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists