From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: ltt-dev@lists.casi.polymtl.ca, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Bryan Wu <cooloney@kernel.org>,
uclinux-dist-devel@blackfin.uclinux.org
Subject: Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)
Date: Thu, 12 Feb 2009 12:02:49 -0800 [thread overview]
Message-ID: <20090212200249.GG6759@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090212192941.GC2047@Krystal>
On Thu, Feb 12, 2009 at 02:29:41PM -0500, Mathieu Desnoyers wrote:
>
> * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> [...]
> > diff --git a/urcu.c b/urcu.c
> > index f2aae34..a696439 100644
> > --- a/urcu.c
> > +++ b/urcu.c
> > @@ -99,7 +99,8 @@ static void force_mb_single_thread(pthread_t tid)
> > * BUSY-LOOP.
> > */
> > while (sig_done < 1)
> > - smp_rmb(); /* ensure we re-read sig-done */
> > + barrier(); /* ensure compiler re-reads sig-done */
> > + /* cache coherence guarantees CPU re-read. */
>
> OK, this is where I think our points of view differ. Please refer to
> http://lkml.org/lkml/2007/6/18/299.
>
> Basically, cpu_relax() used in the Linux kernel has an
> architecture-specific implementation which *could* include a smp_rmb()
> if the architecture doesn't notice writes done by other CPUs. I think
> Blackfin is the only architecture currently supported by the Linux
> kernel which defines cpu_relax() as a smp_mb(), because it does not have
> cache coherency.
>
> Therefore, I propose that we create a memory barrier macro which is
> defined as a
> barrier() when the cpu has cache coherency
> cache flush when the cpu does not have cache coherency and is
> compiled with smp support.
>
> We could call that
>
> smp_wmc() (for memory-coherency or memory commit)
> smp_rmc()
> smp_mc()
>
> It would be a good way to identify the location where data exchange
> between memory and the local cache are is required in the algorithm.
> What do you think ?
Actually the best way to do this would be:
while (ACCESS_ONCE(sig_done) < 1)
continue;
If ACCESS_ONCE() needs to be made architecture-specific to make this
really work on Blackfin, we should make that change. And, now that
you mention it, I have heard rumors that other CPU families can violate
cache coherence in some circumstances.
So perhaps ACCESS_ONCE() becomes:
#ifdef CONFIG_ARCH_CACHE_COHERENT
#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
#else /* #ifdef CONFIG_ARCH_CACHE_COHERENT */
#define ACCESS_ONCE(x) ({ \
typeof(x) _________x1; \
_________x1 = (*(volatile typeof(x) *)&(x)); \
cpu_relax(); \
(_________x1); \
})
#endif /* #else #ifdef CONFIG_ARCH_CACHE_COHERENT */
Seem reasonable?
Thanx, Paul
next prev parent reply other threads:[~2009-02-12 20:03 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-06 3:05 [RFC git tree] Userspace RCU (urcu) for Linux Mathieu Desnoyers
2009-02-06 4:58 ` [RFC git tree] Userspace RCU (urcu) for Linux (repost) Mathieu Desnoyers
2009-02-06 13:06 ` Paul E. McKenney
2009-02-06 16:34 ` Paul E. McKenney
2009-02-07 15:10 ` Paul E. McKenney
2009-02-07 22:16 ` Paul E. McKenney
2009-02-08 0:19 ` Mathieu Desnoyers
2009-02-07 23:38 ` Mathieu Desnoyers
2009-02-08 0:44 ` Paul E. McKenney
2009-02-08 21:46 ` Mathieu Desnoyers
2009-02-08 22:36 ` Paul E. McKenney
2009-02-09 0:24 ` Paul E. McKenney
2009-02-09 0:54 ` Mathieu Desnoyers
2009-02-09 1:08 ` [ltt-dev] " Mathieu Desnoyers
2009-02-09 3:47 ` Paul E. McKenney
2009-02-09 3:42 ` Paul E. McKenney
2009-02-09 0:40 ` [ltt-dev] " Mathieu Desnoyers
2009-02-08 22:44 ` Mathieu Desnoyers
2009-02-09 4:11 ` Paul E. McKenney
2009-02-09 4:53 ` Mathieu Desnoyers
2009-02-09 5:17 ` [ltt-dev] " Mathieu Desnoyers
2009-02-09 7:03 ` Mathieu Desnoyers
2009-02-09 15:33 ` Paul E. McKenney
2009-02-10 19:17 ` Mathieu Desnoyers
2009-02-10 21:16 ` Paul E. McKenney
2009-02-10 21:28 ` Mathieu Desnoyers
2009-02-10 22:21 ` Paul E. McKenney
2009-02-10 22:58 ` Paul E. McKenney
2009-02-10 23:01 ` Paul E. McKenney
2009-02-11 0:57 ` Mathieu Desnoyers
2009-02-11 5:28 ` Paul E. McKenney
2009-02-11 6:35 ` Mathieu Desnoyers
2009-02-11 15:32 ` Paul E. McKenney
2009-02-11 18:52 ` Mathieu Desnoyers
2009-02-11 20:09 ` Paul E. McKenney
2009-02-11 21:42 ` Mathieu Desnoyers
2009-02-11 22:08 ` Mathieu Desnoyers
[not found] ` <20090212003549.GU6694@linux.vnet.ibm.com>
2009-02-12 2:33 ` Paul E. McKenney
2009-02-12 2:37 ` Paul E. McKenney
2009-02-12 4:10 ` Mathieu Desnoyers
2009-02-12 5:09 ` Paul E. McKenney
2009-02-12 5:47 ` Mathieu Desnoyers
2009-02-12 16:18 ` Paul E. McKenney
2009-02-12 18:40 ` Mathieu Desnoyers
2009-02-12 20:28 ` Paul E. McKenney
2009-02-12 21:27 ` Mathieu Desnoyers
2009-02-12 23:26 ` Paul E. McKenney
2009-02-13 13:12 ` Mathieu Desnoyers
2009-02-12 4:08 ` Mathieu Desnoyers
2009-02-12 5:01 ` Paul E. McKenney
2009-02-12 7:05 ` Mathieu Desnoyers
2009-02-12 16:46 ` Paul E. McKenney
2009-02-12 19:29 ` Mathieu Desnoyers
2009-02-12 20:02 ` Paul E. McKenney [this message]
2009-02-12 20:09 ` Mathieu Desnoyers
2009-02-12 20:35 ` Paul E. McKenney
2009-02-12 21:15 ` Mathieu Desnoyers
2009-02-12 20:13 ` Linus Torvalds
2009-02-12 20:39 ` Paul E. McKenney
2009-02-12 21:15 ` Linus Torvalds
2009-02-12 21:59 ` Paul E. McKenney
2009-02-13 13:50 ` Nick Piggin
2009-02-13 14:56 ` Paul E. McKenney
2009-02-13 15:10 ` Mathieu Desnoyers
2009-02-13 15:55 ` Mathieu Desnoyers
2009-02-13 16:18 ` Linus Torvalds
2009-02-13 17:33 ` Mathieu Desnoyers
2009-02-13 17:53 ` Linus Torvalds
2009-02-13 18:09 ` Linus Torvalds
2009-02-13 18:54 ` Mathieu Desnoyers
2009-02-13 19:36 ` Paul E. McKenney
2009-02-14 5:07 ` Mike Frysinger
2009-02-14 5:20 ` Paul E. McKenney
2009-02-14 5:46 ` Mike Frysinger
2009-02-14 15:06 ` Paul E. McKenney
2009-02-14 17:37 ` Mike Frysinger
2009-02-22 14:23 ` Pavel Machek
2009-02-22 18:28 ` Mike Frysinger
2009-02-14 6:42 ` Mathieu Desnoyers
2009-02-14 3:15 ` [Uclinux-dist-devel] " Mike Frysinger
2009-02-13 18:40 ` Mathieu Desnoyers
2009-02-13 16:05 ` Linus Torvalds
2009-02-14 3:11 ` [Uclinux-dist-devel] " Mike Frysinger
2009-02-14 4:58 ` Robin Getz
2009-02-12 19:38 ` Mathieu Desnoyers
2009-02-12 20:17 ` Paul E. McKenney
2009-02-12 21:53 ` Mathieu Desnoyers
2009-02-12 23:04 ` Paul E. McKenney
2009-02-13 12:49 ` Mathieu Desnoyers
2009-02-11 5:08 ` Lai Jiangshan
2009-02-11 8:58 ` Mathieu Desnoyers
2009-02-09 13:23 ` Paul E. McKenney
2009-02-09 17:28 ` Mathieu Desnoyers
2009-02-09 17:47 ` Paul E. McKenney
2009-02-09 18:13 ` Mathieu Desnoyers
2009-02-09 18:19 ` Mathieu Desnoyers
2009-02-09 18:37 ` Paul E. McKenney
2009-02-09 18:49 ` Paul E. McKenney
2009-02-09 19:05 ` Mathieu Desnoyers
2009-02-09 19:15 ` Mathieu Desnoyers
2009-02-09 19:35 ` Paul E. McKenney
2009-02-09 19:23 ` Paul E. McKenney
2009-02-09 13:16 ` Paul E. McKenney
2009-02-09 17:19 ` Bert Wesarg
2009-02-09 17:34 ` Paul E. McKenney
2009-02-09 17:35 ` Bert Wesarg
2009-02-09 17:40 ` Paul E. McKenney
2009-02-09 17:42 ` Mathieu Desnoyers
2009-02-09 18:00 ` Paul E. McKenney
2009-02-09 17:45 ` Bert Wesarg
2009-02-09 17:59 ` Paul E. McKenney
2009-02-07 22:56 ` Kyle Moffett
2009-02-07 23:50 ` Mathieu Desnoyers
2009-02-08 0:13 ` Paul E. McKenney
2009-02-06 8:55 ` [RFC git tree] Userspace RCU (urcu) for Linux Bert Wesarg
2009-02-06 11:36 ` Mathieu Desnoyers
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=20090212200249.GG6759@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=compudj@krystal.dyndns.org \
--cc=cooloney@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@lists.casi.polymtl.ca \
--cc=torvalds@linux-foundation.org \
--cc=uclinux-dist-devel@blackfin.uclinux.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.