[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.281 / U:4.888 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site