lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <46CAED8B.9030006@redhat.com> Date: Tue, 21 Aug 2007 09:50:03 -0400 From: Chris Snook <csnook@...hat.com> To: David Miller <davem@...emloft.net> CC: torvalds@...ux-foundation.org, piggin@...erone.com.au, satyam@...radead.org, herbert@...dor.apana.org.au, paulus@...ba.org, clameter@....com, ilpo.jarvinen@...sinki.fi, paulmck@...ux.vnet.ibm.com, stefanr@...6.in-berlin.de, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, netdev@...r.kernel.org, akpm@...ux-foundation.org, ak@...e.de, heiko.carstens@...ibm.com, 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, segher@...nel.crashing.org Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures David Miller wrote: > From: Linus Torvalds <torvalds@...ux-foundation.org> > 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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists