From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: herbert@gondor.apana.org.au, csnook@redhat.com,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
ak@suse.de, heiko.carstens@de.ibm.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
schwidefsky@de.ibm.com, wensong@linux-vs.org, horms@verge.net.au,
wjiang@resilience.com, cfriesen@nortel.com, zlynx@acm.org
Subject: Re: [PATCH] make atomic_t volatile on all architectures
Date: Wed, 8 Aug 2007 20:47:20 -0700 [thread overview]
Message-ID: <20070809034720.GA12996@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070808.184824.133910636.davem@davemloft.net>
On Wed, Aug 08, 2007 at 06:48:24PM -0700, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu, 09 Aug 2007 09:03:27 +0800
>
> > Such loops should always use something like cpu_relax() which comes
> > with a barrier.
>
> This is an excellent point.
>
> And it needs to be weighed with the error prone'ness Andrew mentioned.
> There probably is a middle ground somewhere.
OK... I'll bite. ACCESS_ONCE(), see http://lkml.org/lkml/2007/7/11/664.
This would allow ACCESS_ONCE(atomic_read(&x)) to be used where refetching
would be problematic, but allow the compiler free rein in cases where
refetching is OK.
The ACCESS_ONCE() primitive of course has its limitations as well, but
you did ask for a middle ground. ;-)
Thanx, Paul
next prev parent reply other threads:[~2007-08-09 3:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-08 23:07 [PATCH] make atomic_t volatile on all architectures Chris Snook
2007-08-08 23:18 ` Jesper Juhl
2007-08-08 23:31 ` Chris Snook
2007-08-08 23:51 ` Jesper Juhl
2007-08-08 23:25 ` Lennert Buytenhek
2007-08-08 23:35 ` Chris Snook
2007-08-09 1:03 ` Herbert Xu
2007-08-09 1:48 ` David Miller
2007-08-09 3:47 ` Paul E. McKenney [this message]
2007-08-09 7:47 ` Chris Snook
2007-08-09 8:30 ` Herbert Xu
2007-08-09 11:44 ` Chris Snook
2007-08-09 4:18 ` Linus Torvalds
2007-08-09 4:59 ` Jerry Jiang
2007-08-09 7:31 ` Chris Snook
2007-08-09 8:14 ` Heiko Carstens
2007-08-09 17:36 ` Chuck Ebbert
2007-08-09 17:55 ` Linus Torvalds
2007-08-09 18:20 ` Martin Schwidefsky
2007-08-12 5:53 ` Segher Boessenkool
2007-08-12 6:09 ` Linus Torvalds
2007-08-12 9:48 ` Martin Schwidefsky
2007-08-12 9:54 ` Linus Torvalds
2007-08-12 16:30 ` Segher Boessenkool
2007-08-12 18:11 ` Linus Torvalds
2007-08-12 19:13 ` Segher Boessenkool
2007-08-12 10:27 ` Segher Boessenkool
2007-08-12 17:59 ` Linus Torvalds
2007-08-12 9:47 ` Martin Schwidefsky
2007-08-12 10:35 ` Segher Boessenkool
2007-08-09 17:57 ` Martin Schwidefsky
[not found] <8Q2Pg-8uV-23@gated-at.bofh.it>
[not found] ` <8Q7Fa-7rJ-1@gated-at.bofh.it>
[not found] ` <8Q8rD-hh-7@gated-at.bofh.it>
2007-08-09 9:10 ` Bodo Eggert
2007-08-09 9:10 ` Bodo Eggert
2007-08-09 9:18 ` Jerry Jiang
2007-08-09 15:00 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070809034720.GA12996@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=csnook@redhat.com \
--cc=davem@davemloft.net \
--cc=heiko.carstens@de.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=wensong@linux-vs.org \
--cc=wjiang@resilience.com \
--cc=zlynx@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.