lkml.org 
[lkml]   [2007]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2007-08-16 03:13    [W:0.025 / U:0.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site