* Paul E. McKenney ([email protected]) wrote: > On Tue, Jun 15, 2010 at 06:07:20PM +0200, Ulrich Weigand wrote: > > "Paul E. McKenney" <[email protected]> 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
