[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200708171052.39477.ak@suse.de>
Date: Fri, 17 Aug 2007 10:52:37 +0200
From: Andi Kleen <ak@...e.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Paul Mackerras <paulus@...ba.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Segher Boessenkool <segher@...nel.crashing.org>,
heiko.carstens@...ibm.com, horms@...ge.net.au,
linux-kernel@...r.kernel.org, rpjday@...dspring.com,
netdev@...r.kernel.org, cfriesen@...tel.com,
akpm@...ux-foundation.org, jesper.juhl@...il.com,
linux-arch@...r.kernel.org, zlynx@....org, satyam@...radead.org,
clameter@....com, schwidefsky@...ibm.com,
Chris Snook <csnook@...hat.com>,
Herbert Xu <herbert.xu@...hat.com>, davem@...emloft.net,
wensong@...ux-vs.org, wjiang@...ilience.com
Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Friday 17 August 2007 05:42, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> > I'm really surprised it's as much as a few K. I tried it on powerpc
> > and it only saved 40 bytes (10 instructions) for a G5 config.
>
> One of the things that "volatile" generally screws up is a simple
>
> volatile int i;
>
> i++;
But for atomic_t people use atomic_inc() anyways which does this correctly.
It shouldn't really matter for atomic_t.
I'm worrying a bit that the volatile atomic_t change caused subtle code
breakage like these delay read loops people here pointed out.
Wouldn't it be safer to just re-add the volatile to atomic_read()
for 2.6.23? Or alternatively make it asm(), but volatile seems more
proven.
-Andi
-
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