[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46C3B40D.3010909@nortel.com>
Date: Wed, 15 Aug 2007 20:18:53 -0600
From: "Chris Friesen" <cfriesen@...tel.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: Satyam Sharma <satyam@...radead.org>,
Christoph Lameter <clameter@....com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Paul Mackerras <paulus@...ba.org>,
Stefan Richter <stefanr@...6.in-berlin.de>,
Chris Snook <csnook@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
netdev@...r.kernel.org, Andrew Morton <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, 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
Herbert Xu wrote:
> But I have to say that I still don't know of a single place
> where one would actually use the volatile variant.
Given that many of the existing users do currently have "volatile", are
you comfortable simply removing that behaviour from them? Are you sure
that you will not introduce any issues?
Forcing a re-read is only a performance penalty. Removing it can cause
behavioural changes.
I would be more comfortable making the default match the majority of the
current implementations (ie: volatile semantics). Then, if someone
cares about performance they can explicitly validate the call path and
convert it over to the non-volatile version.
Correctness before speed...
Chris
-
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