[lkml]   [2007]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    David Miller wrote:
    > From: Linus Torvalds <>
    > Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
    >> Ie a "barrier()" is likely _cheaper_ than the code generation downside
    >> from using "volatile".
    > Assuming GCC were ever better about the code generation badness
    > with volatile that has been discussed here, I much prefer
    > we tell GCC "this memory piece changed" rather than "every
    > piece of memory has changed" which is what the barrier() does.
    > I happened to have been scanning a lot of assembler lately to
    > track down a gcc-4.2 miscompilation on sparc64, and the barriers
    > do hurt quite a bit in some places. Instead of keeping unrelated
    > variables around cached in local registers, it reloads everything.

    Moore's law is definitely working against us here. Register counts,
    pipeline depths, core counts, and clock multipliers are all increasing
    in the long run. At some point in the future, barrier() will be
    universally regarded as a hammer too big for most purposes. Whether or
    not removing it now constitutes premature optimization is arguable, but
    I think we should allow such optimization to happen (or not happen) in
    architecture-dependent code, and provide a consistent API that doesn't
    require the use of such things in arch-independent code where it might
    turn into a totally superfluous performance killer depending on what
    hardware it gets compiled for.

    -- Chris
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-21 16:29    [W:0.020 / U:7.868 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site