[ltt-dev] [PATCH] fix the "unknown" case

[Mathieu Desnoyers]

* Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> 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!

I wonder starting with which Linux kernel version __kernel_dmb appeared.
Tying ourself directly to a Linux kernel ABI might complicate things.

Is this ABI presented in a vDSO or userland have to go through a system call ?
Is there any way to probe for its availability ?

Thanks,

Mathieu

> 
> 							Thanx, Paul

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com