linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/5] Switch arm64 over to qrwlock
Date: Mon, 9 Oct 2017 11:02:47 +0100	[thread overview]
Message-ID: <20171009100246.GD5127@arm.com> (raw)
In-Reply-To: <20171009065243.g4q7l3kf2esa4fkk@hirez.programming.kicks-ass.net>

On Mon, Oct 09, 2017 at 08:52:43AM +0200, Peter Zijlstra wrote:
> On Mon, Oct 09, 2017 at 12:30:52AM +0300, Yury Norov wrote:
> > The bottomline of discussion [1] was that queued locks are more
> > effective when SoC has many CPUs. And 4 is not many.
> 
> qspinlock, yes. qrwlock not, as it fully depends on arch_spinlock_t for
> the queueing. qrwlock is just a generic rwlock_t implementation.

Yup, and once I've knocked qrwlocks on the head I'll go take a look at
qspinlock. Either way, I'll keep our ticket implementation around because
(a) it's a tonne simpler (b) I don't have data to suggest that it sucks and
(c) there's been formal work to show that various parts of it are correct.

rwlock on the other hand has been shown to be broken, I know that it sucks
and there's not been any formal work, so I'll be glad to see the back of it!

Will

  reply	other threads:[~2017-10-09 10:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06 13:34 [PATCH v2 0/5] Switch arm64 over to qrwlock Will Deacon
2017-10-06 13:34 ` [PATCH v2 1/5] kernel/locking: Use struct qrwlock instead of struct __qrwlock Will Deacon
2017-10-06 13:34 ` [PATCH v2 2/5] locking/atomic: Add atomic_cond_read_acquire Will Deacon
2017-10-06 13:34 ` [PATCH v2 3/5] kernel/locking: Use atomic_cond_read_acquire when spinning in qrwlock Will Deacon
2017-10-08  1:03   ` Boqun Feng
2017-10-09 11:30     ` Will Deacon
2017-10-06 13:34 ` [PATCH v2 4/5] arm64: locking: Move rwlock implementation over to qrwlocks Will Deacon
2017-10-10  1:34   ` Waiman Long
2017-10-11 11:49     ` Will Deacon
2017-10-11 14:03       ` Waiman Long
2017-10-06 13:34 ` [PATCH v2 5/5] kernel/locking: Prevent slowpath writers getting held up by fastpath Will Deacon
2017-10-08 21:30 ` [PATCH v2 0/5] Switch arm64 over to qrwlock Yury Norov
2017-10-09  6:52   ` Peter Zijlstra
2017-10-09 10:02     ` Will Deacon [this message]
2017-10-09  9:59   ` Will Deacon
2017-10-09 12:49     ` Yury Norov
2017-10-09 13:13       ` Will Deacon
2017-10-09 21:19 ` Waiman Long
2017-10-09 22:31 ` Jeremy Linton
2017-10-10 18:20 ` Adam Wallis

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=20171009100246.GD5127@arm.com \
    --to=will.deacon@arm.com \
    --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;
as well as URLs for NNTP newsgroup(s).