All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Sullivan <nathan.sullivan@ni.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Yong Zhang <yong.zhang0@gmail.com>,
	Yong Zhang <yong.zhang@windriver.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: __HAVE_ARCH_CMPXCHG on ARM?
Date: Tue, 3 Feb 2015 10:48:48 -0600	[thread overview]
Message-ID: <20150203164848.GA15156@nathan3500-linux-VM> (raw)
In-Reply-To: <20150202133933.GD31847@arm.com>

On Mon, Feb 02, 2015 at 01:39:33PM +0000, Will Deacon wrote:
> 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@ni.com<mailto:nathan.sullivan@ni.com>> 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@windriver.com<mailto:yong.zhang@windriver.com>>
> 
> [...]
> 
> > 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

What about single Cortex-A8s, for example?  Seems like a non-SMP build should still
have cmpxchg.

Nathan

WARNING: multiple messages have this Message-ID (diff)
From: nathan.sullivan@ni.com (Nathan Sullivan)
To: linux-arm-kernel@lists.infradead.org
Subject: __HAVE_ARCH_CMPXCHG on ARM?
Date: Tue, 3 Feb 2015 10:48:48 -0600	[thread overview]
Message-ID: <20150203164848.GA15156@nathan3500-linux-VM> (raw)
In-Reply-To: <20150202133933.GD31847@arm.com>

On Mon, Feb 02, 2015 at 01:39:33PM +0000, Will Deacon wrote:
> 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 at ni.com<mailto:nathan.sullivan@ni.com>> 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 at windriver.com<mailto:yong.zhang@windriver.com>>
> 
> [...]
> 
> > 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

What about single Cortex-A8s, for example?  Seems like a non-SMP build should still
have cmpxchg.

Nathan

  reply	other threads:[~2015-02-03 16:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29 18:56 __HAVE_ARCH_CMPXCHG on ARM? Nathan Sullivan
2015-01-29 18:56 ` Nathan Sullivan
     [not found] ` <CAM2zO=CVCZFNiSukgcgNNT0==xgLK4w5HF3Pz=dcFmrEHPtLdw@mail.gmail.com>
2015-02-02 13:39   ` Will Deacon
2015-02-02 13:39     ` Will Deacon
2015-02-03 16:48     ` Nathan Sullivan [this message]
2015-02-03 16:48       ` Nathan Sullivan
2015-02-03 16:57       ` Will Deacon
2015-02-03 16:57         ` Will Deacon
2015-02-03 19:27     ` Josh Cartwright
2015-02-03 19:27       ` Josh Cartwright
2015-02-18 10:44       ` Sebastian Andrzej Siewior
2015-02-18 10:44         ` Sebastian Andrzej Siewior
2015-02-18 16:34         ` Josh Cartwright
2015-02-18 16:34           ` Josh Cartwright
2015-02-18 10:43     ` Sebastian Andrzej Siewior
2015-02-18 10:43       ` Sebastian Andrzej Siewior

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=20150203164848.GA15156@nathan3500-linux-VM \
    --to=nathan.sullivan@ni.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=will.deacon@arm.com \
    --cc=yong.zhang0@gmail.com \
    --cc=yong.zhang@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.