Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
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




  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