From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <waiman.long@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-arch@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michel Lespinasse <walken@google.com>,
Andi Kleen <andi@firstfloor.org>, Rik van Riel <riel@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
George Spelvin <linux@horizon.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
aswin@hp.com, Scott J Norton <scott.norton@hp.com>
Subject: Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation
Date: Fri, 31 Jan 2014 20:47:18 +0100 [thread overview]
Message-ID: <20140131194718.GO5002@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <52EBF276.1020505@hp.com>
On Fri, Jan 31, 2014 at 01:59:02PM -0500, Waiman Long wrote:
> On 01/31/2014 04:26 AM, Peter Zijlstra wrote:
> >On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
> >>The below is still small and actually works.
> >OK, so having actually worked through the thing; I realized we can
> >actually do a version without MCS lock and instead use a ticket lock for
> >the waitqueue.
> >
> >This is both smaller (back to 8 bytes for the rwlock_t), and should be
> >faster under moderate contention for not having to touch extra
> >cachelines.
> >
> >Completely untested and with a rather crude generic ticket lock
> >implementation to illustrate the concept:
> >
>
> Using a ticket lock instead will have the same scalability problem as the
> ticket spinlock as all the waiting threads will spin on the lock cacheline
> causing a lot of cache bouncing traffic. That is the reason why I want to
> replace ticket spinlock with queue spinlock.
But but but, just fix such heavily contended locks. Don't make sensible
code that is lightly contended run slower because of it.
next prev parent reply other threads:[~2014-01-31 19:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 4:28 [PATCH v11 0/4] Introducing a queue read/write lock implementation Waiman Long
2014-01-24 4:28 ` [PATCH v11 1/4] qrwlock: A " Waiman Long
2014-01-24 8:25 ` Peter Zijlstra
2014-01-25 4:39 ` Waiman Long
2014-01-24 4:28 ` [PATCH v11 2/4] qrwlock, x86: Enable x86 to use queue read/write lock Waiman Long
2014-01-24 4:28 ` [PATCH v11 3/4] qrwlock, x86: Add char and short as atomic data type in x86 Waiman Long
2014-01-24 4:28 ` [PATCH v11 4/4] qrwlock: Use the mcs_spinlock helper functions for MCS queuing Waiman Long
2014-01-24 8:26 ` Peter Zijlstra
2014-01-25 4:30 ` Waiman Long
2014-01-30 13:04 ` [PATCH v11 0/4] Introducing a queue read/write lock implementation Peter Zijlstra
2014-01-30 15:17 ` Peter Zijlstra
2014-01-30 15:43 ` Waiman Long
2014-01-30 15:50 ` Waiman Long
2014-01-30 15:53 ` Peter Zijlstra
2014-01-30 15:44 ` Peter Zijlstra
2014-01-30 17:52 ` Will Deacon
2014-01-30 18:05 ` Peter Zijlstra
2014-01-30 18:11 ` Will Deacon
2014-01-30 18:16 ` Peter Zijlstra
2014-01-31 9:26 ` Peter Zijlstra
2014-01-31 10:03 ` George Spelvin
2014-01-31 10:17 ` Peter Zijlstra
2014-01-31 11:30 ` Peter Zijlstra
2014-02-01 23:22 ` Paul E. McKenney
2014-01-31 18:59 ` Waiman Long
2014-01-31 19:47 ` Peter Zijlstra [this message]
2014-02-01 10:38 ` George Spelvin
2014-01-31 20:14 ` Peter Zijlstra
2014-01-31 21:09 ` Waiman Long
2014-02-01 1:29 ` Davidlohr Bueso
2014-02-02 9:03 ` Ingo Molnar
2014-02-03 11:38 ` Peter Zijlstra
2014-02-06 3:08 ` 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=20140131194718.GO5002@laptop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arnd@arndb.de \
--cc=aswin@hp.com \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=waiman.long@hp.com \
--cc=walken@google.com \
--cc=x86@kernel.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).