public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] arm: Add for atomic half word exchange
Date: Wed, 20 May 2015 08:51:32 +0200	[thread overview]
Message-ID: <2528978.P5FT0BVksd@wuerfel> (raw)
In-Reply-To: <1348896100.440561432098574765.JavaMail.weblogic@ep2mlwas07a>

On Wednesday 20 May 2015 05:09:35 Sarbojit Ganguly wrote:

> > ------- Original Message -------
> > Sender : Peter Zijlstra<peterz@infradead.org>
> > Date : May 19, 2015 21:43 (GMT+09:00)
> > Title : Re: [RFC] arm: Add for atomic half word exchange
> > 
> > On Tue, May 19, 2015 at 11:20:13AM +0000, Sarbojit Ganguly wrote:
> > > On Tuesday 19 May 2015 09:39:33 Sarbojit Ganguly wrote:
> > > > Since 16 bit half word exchange was not there and MCS based
> > > > qspinlock by Waiman's xchg_tail() requires an atomic exchange on a
> > > > half word, here is a small modification to __xchg() code.
> > 
> > Can you actually see a performance improvement with the qspinlock code
> > on ARM ?
> > 
> > The real improvements on x86 were on NUMA systems; although there were
> > real improvements on light loads as well.
> > 
> > 
> > Note that ARM (or any load-store arch) could get rid of all the cmpxchg
> > loops in that code. Although I suppose we replaced the most common ones
> > with these unconditional atomics already -- like that xchg16 -- so
> > implementing those with ll/sc, as you did, should be near optimal.
>
> Yes, the main advantage of Qspinlock code can be observed in NUMA but
> when I tested in an embedded system, a slight advantage was observed.

Is this a multi-cluster SMP system? Those can behave like NUMA
machines in some ways.

We could easily limit the use of 16-bit xchg() to ARMv7 machines
by using

	select ARCH_USE_QUEUED_SPINLOCKS if !SMP_ON_UP

or

	select ARCH_USE_QUEUED_SPINLOCKS if !CPU_V6

when enabling the qspinlock implementation.

	Arnd

       reply	other threads:[~2015-05-20  6:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1348896100.440561432098574765.JavaMail.weblogic@ep2mlwas07a>
2015-05-20  6:51 ` Arnd Bergmann [this message]
2015-05-20  6:57 ` [RFC] arm: Add for atomic half word exchange Peter Zijlstra
     [not found] <274749765.566061433467033693.JavaMail.weblogic@epmlwas07c>
2015-06-05 12:33 ` Arnd Bergmann
     [not found] <146879519.394951433226103227.JavaMail.weblogic@epmlwas06d>
2015-06-02 10:49 ` Arnd Bergmann
     [not found] <1357570181.391771433224164775.JavaMail.weblogic@epmlwas06d>
2015-06-02  6:11 ` Raghavendra K T
2015-05-19 11:20 Sarbojit Ganguly
2015-05-19 11:42 ` Arnd Bergmann
2015-05-19 12:13 ` Russell King - ARM Linux
2015-05-19 12:43 ` Peter Zijlstra
  -- strict thread matches above, loose matches on Subject: below --
2015-05-19  9:39 Sarbojit Ganguly
2015-05-19  9:51 ` Arnd Bergmann

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=2528978.P5FT0BVksd@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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