On Fri, Jan 30, 2015 at 08:44:48AM +0000, Yong Zhang wrote: > On Fri, Jan 30, 2015 at 2:56 AM, Nathan Sullivan <nathan.sullivan@xxxxxx<mailto:nathan.sullivan@xxxxxx>> wrote: > > While investigating a performance issue on RT 3.14, I noticed that > __HAVE_ARCH_CMPXCHG is not defined for ARM. This causes -rt locks to > always use the slow path and impacts performance. ARMv6 and above > have a cmpxchg implementation already that will work just fine. > > In 2012, Yong Zhang submitted a patch to fix this[1], but it mysteriously > disappeared afterwards. I did notice that the s-o-b line has a different > email address than the windriver one. Yong, do you mind re-submitting the > > It actually doesn't matter. Anyway feel free to add another s-o-b to > the patch: > > Signed-off-by: Yong Zhang <yong.zhang@xxxxxxxxxxxxx<mailto:yong.zhang@xxxxxxxxxxxxx>> [...] > diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h > index 7eb18c1..a91b44e 100644 > --- a/arch/arm/include/asm/cmpxchg.h > +++ b/arch/arm/include/asm/cmpxchg.h > @@ -127,6 +127,8 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size > > #else /* min ARCH >= ARMv6 */ > > +#define __HAVE_ARCH_CMPXCHG 1 Is it even possible to have CONFIG_SMP=y on an architecture that doesn't support native cmpxchg? Certainly, the asm-generic cmpxchg.h barfs if SMP, so couldn't we just change/extend the __HAVE_ARCH_CMPXCHG check in rtmutex.c to work automatically with SMP architectures? That would help arm64 too. Will -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
