From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
Subject: [ltt-dev] [PATCH] fix the "unknown" case
Date: Tue, 15 Jun 2010 10:00:01 -0700 [thread overview]
Message-ID: <20100615170001.GG2304@linux.vnet.ibm.com> (raw)
In-Reply-To: <OFCD1BC564.0035E292-ONC1257743.0057CB53-C1257743.0058903F@de.ibm.com>
On Tue, Jun 15, 2010 at 06:07:20PM +0200, Ulrich Weigand wrote:
> "Paul E. McKenney" <paulmck at linux.vnet.ibm.com> wrote on 06/15/2010
> 05:07:27 PM:
>
> > > See also the discussion in this bugzilla and the mailing list threads
> > > linked from it:
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42263
> >
> > So I cannot expect the other __sync_ primitives to be generate
> > memory barriers, either, correct? Hmmm... From looking at
> > http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00198.html, I wonder
> > whether I can rely on them to be using atomic instructions -- though
> > I do admit that __sync_lock_release() often does not need an atomic
> > instruction.
>
> As mentioned in the bugzilla, there were bugs in __sync_synchronize
> (which was just a compiler optimization barrier), and in
> __sync_lock_release,
> which did use a memory barrier, but at the wrong place.
>
> With a compiler where these two are fixes (GCC 4.4.3 and above), all the
> __sync_ primitives will generate memory barriers, but not directly: the
> compiler will call the libgcc library function, which will call a special
> ARM kernel entry point, which will then use an appropriate instruction
> depending whether the kernel is compiled for SMP or UP, and depending on
> the target instruction set level. For example, the __kernel_dmb call
> uses this piece of code in the kernel:
>
> .macro smp_dmb
> #ifdef CONFIG_SMP
> #if __LINUX_ARM_ARCH__ >= 7
> dmb
> #elif __LINUX_ARM_ARCH__ == 6
> mcr p15, 0, r0, c7, c10, 5 @ dmb
> #endif
> #endif
> .endm
OK, so GCC 4.4.3 and above can be trusted.
> > So, should I just bite the bullet and write the usual set of asms
> > myself? People are going to want to build liburcu on old compilers,
> > sad to say...
>
> As Paolo already said, you probably do want to support older compilers.
> On the other hand, if you hard-code the dmb instruction, it seems you're
> tied to the ARM 7 architecture level ... Maybe you want to directly
> use the __kernel_dmb etc. calls in liburcu? They seem to be official
> kernel ABI, so should be OK to use.
My current autoconf code checks for "armv7l", so I am OK being ARMv7
specific. But it would be really good to cover the rest of the ARM
family, and __kernel_dmb and friends might be a way to do that!
Thanx, Paul
next prev parent reply other threads:[~2010-06-15 17:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100614220600.GA15130@linux.vnet.ibm.com>
2010-06-15 12:35 ` Ulrich Weigand
2010-06-15 15:07 ` Paul E. McKenney
2010-06-15 15:18 ` Paolo Bonzini
2010-06-15 16:21 ` Paul E. McKenney
2010-06-15 16:07 ` Ulrich Weigand
2010-06-15 17:00 ` Paul E. McKenney [this message]
2010-06-15 17:03 ` Mathieu Desnoyers
2010-06-15 17:32 ` Ulrich Weigand
2010-06-15 18:29 ` [ltt-dev] Userspace helpers at static addresses on ARM [was: Re: [PATCH] fix the "unknown" case] Mathieu Desnoyers
2010-06-15 19:02 ` Paul E. McKenney
[not found] <20100610225242.GA21978@linux.vnet.ibm.com>
[not found] ` <20100611014631.GA13838@Krystal>
[not found] ` <20100611171613.GD2394@linux.vnet.ibm.com>
[not found] ` <20100613212033.GF5427@Krystal>
[not found] ` <20100613212807.GF2428@linux.vnet.ibm.com>
2010-06-13 21:36 ` [ltt-dev] [PATCH] fix the "unknown" case Mathieu Desnoyers
2010-06-14 0:52 ` Paul E. McKenney
2010-06-14 2:08 ` Mathieu Desnoyers
2010-06-14 2:46 ` Mathieu Desnoyers
2010-06-14 5:11 ` Paul E. McKenney
2010-06-14 5:41 ` Paul E. McKenney
2010-06-14 17:04 ` Paolo Bonzini
2010-06-14 18:25 ` Paul E. McKenney
2010-06-15 8:52 ` Paolo Bonzini
2010-06-15 14:57 ` Paul E. McKenney
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=20100615170001.GG2304@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox