From: Waiman Long <longman@redhat•com>
To: Will Deacon <will@kernel•org>,
Sebastian Andrzej Siewior <sebastian@breakpoint•cc>
Cc: Peter Zijlstra <peterz@infradead•org>,
Ingo Molnar <mingo@redhat•com>, Arnd Bergmann <arnd@arndb•de>,
linux-arm-kernel@lists•infradead.org,
Russell King <linux@armlinux•org.uk>
Subject: Re: [RFC PATCH 0/6 v2] Queued spinlocks/RW-locks for ARM
Date: Wed, 16 Oct 2019 13:45:13 -0400 [thread overview]
Message-ID: <a14cbac0-3eab-c136-ad2d-9b4d8b95a098@redhat.com> (raw)
In-Reply-To: <20191016155755.66ges3ybn3awx45l@willie-the-truck>
On 10/16/19 11:57 AM, Will Deacon wrote:
> Hi Sebastian,
>
> On Mon, Oct 14, 2019 at 12:13:04AM +0200, Sebastian Andrzej Siewior wrote:
>> I added support for queued-RW and -spinlocks for ARM. I followed Arnd's
>> suggestion and added support for xchg() on 8bit and 16bit variables (V6
>> CPUs) via the SH implementation. This makes it possible to remove the
>> current ticket based locking implementation.
>>
>> The numbers should be the same as in v1 posted here:
>> http://lkml.kernel.org/r/20191007214439.27891-1-sebastian@breakpoint.cc
>>
>> The only thing changed is that patch #1-#3 wire up the missing xchg and
>> the patches #4 and #5 additionally remove the old implementation while
>> adding the missing bits for the queued implementation.
> To be honest with you, I'm surprised that qspinlock is worth it for 32-bit
> Arm. qrwlock makes sense because of fairness and starvation issues, but in
> my benchmarks on arm64 tickets tended to perform at least as well for small
> core counts, and I think that's largely going to be true for systems
> running a 32-bit kernel.
My own testing on qspinlocks in the past, at least on x86-64, is that it
is comparable to ticket lock with one or 2 contending tasks if not
better. When there are 3 contending tasks, qspinlock will then be a bit
slower than ticket lock because the overhead of using the MCS node for
queuing is showing up. Starting with 4 and more contending tasks,
qspinlock starts to show its strength and performing better and better
with more contending tasks.
So if the target is 4 cores or less, there isn't too much to gain from
using qspinlock. Lock function inlining probably has a bigger
performance benefit here than switching to qspinlock. Just food for thought.
Cheers,
Longman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-16 17:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-13 22:13 [RFC PATCH 0/6 v2] Queued spinlocks/RW-locks for ARM Sebastian Andrzej Siewior
2019-10-13 22:13 ` [PATCH 1/6] sh: Move cmpxchg-xchg.h to asm-generic Sebastian Andrzej Siewior
2019-10-14 7:25 ` Arnd Bergmann
2019-10-15 22:31 ` [PATCH 1/6 v2] " Sebastian Andrzej Siewior
2019-10-13 22:13 ` [PATCH 2/6] ARM: cmpxchg: Define first cmpxchg() followed by xchg() Sebastian Andrzej Siewior
2019-10-13 22:13 ` [PATCH 3/6] ARM: Add xchg_{8|16}() on generic cmpxchg() on CPU_V6 Sebastian Andrzej Siewior
2019-10-13 22:13 ` [PATCH 4/6] ARM: Use qrwlock implementation Sebastian Andrzej Siewior
2019-10-13 22:13 ` [PATCH 5/6] ARM: Use qspinlock implementation Sebastian Andrzej Siewior
2019-10-13 22:13 ` [PATCH 6/6] ARM: Inline locking functions for !PREEMPTION Sebastian Andrzej Siewior
2019-10-14 7:43 ` Arnd Bergmann
2019-10-14 10:01 ` Arnd Bergmann
2019-10-15 22:30 ` Sebastian Andrzej Siewior
2019-10-15 22:37 ` Waiman Long
2019-10-15 22:47 ` Arnd Bergmann
2019-10-15 22:04 ` Sebastian Andrzej Siewior
2019-10-14 9:00 ` [RFC PATCH 0/6 v2] Queued spinlocks/RW-locks for ARM Arnd Bergmann
2019-10-16 15:57 ` Will Deacon
2019-10-16 17:45 ` Waiman Long [this message]
2019-10-16 18:33 ` Arnd Bergmann
2019-10-16 21:35 ` Sebastian Andrzej Siewior
2019-10-16 22:09 ` Sebastian Andrzej Siewior
2019-10-17 15:36 ` Waiman Long
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=a14cbac0-3eab-c136-ad2d-9b4d8b95a098@redhat.com \
--to=longman@redhat$(echo .)com \
--cc=arnd@arndb$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux@armlinux$(echo .)org.uk \
--cc=mingo@redhat$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=sebastian@breakpoint$(echo .)cc \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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