From: Andi Kleen <andi@firstfloor.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
Waiman Long <Waiman.Long@hp.com>,
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" <linux-arch@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michel Lespinasse <walken@google.com>,
Rik van Riel <riel@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
George Spelvin <linux@horizon.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Aswin Chandramouleeswaran <aswin@hp.com>,
Scott J Norton <scott.norton@hp.com>
Subject: Re: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock
Date: Mon, 18 Nov 2013 19:46:44 +0100 [thread overview]
Message-ID: <20131118184644.GC29695@two.firstfloor.org> (raw)
In-Reply-To: <CA+55aFyH_BUrrzft-1JGZ5zL=KxGrUESBBOZnzT=nQm6Ld0V+Q@mail.gmail.com>
> Why would it make sense here?
There may be cases were switching all read locks to unfair may make
concerete workloads slower.
The effect is very visible in (non kernel) lock micro benchmarks,
especially with HyperThreading.
With very high contention or long enough critical sections
the ordered lock usually wins, but it loses with lower contention.
Unfortunately the "small critical section" case (even though it's
really bad for any contended lock) is reasonably common :-/
[IMHO all of these should be fixed or "batched" somehow, but in some
cases it is quite hard]
However ordered locks definitely have more consistent performance.
If prioritizing consistency over potential slow down in some cases
is fine only having the ordered option is ok.
-Andi
next prev parent reply other threads:[~2013-11-18 18:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 14:48 [PATCH v6 0/5] qrwlock: Introducing a queue read/write lock implementation Waiman Long
2013-11-12 14:48 ` [PATCH v6 1/5] qrwlock: A " Waiman Long
2013-11-12 14:48 ` [PATCH v6 1/3] " Waiman Long
2013-11-12 14:48 ` Waiman Long
2013-11-12 14:53 ` Waiman Long
2013-11-12 14:48 ` [PATCH v6 2/5] qrwlock x86: Enable x86 to use queue read/write lock Waiman Long
2013-11-12 14:48 ` Waiman Long
2013-11-12 14:48 ` [PATCH v6 3/5] qrwlock: Enable fair " Waiman Long
2013-11-12 14:48 ` Waiman Long
2013-11-18 18:11 ` Linus Torvalds
2013-11-18 18:34 ` Andi Kleen
2013-11-18 18:38 ` Linus Torvalds
2013-11-18 18:46 ` Andi Kleen [this message]
2013-11-18 18:46 ` Andi Kleen
2013-11-18 18:55 ` Linus Torvalds
2013-11-18 18:55 ` Linus Torvalds
2013-11-19 4:33 ` Long, Wai Man
2013-11-12 14:48 ` [PATCH v6 4/5] qrwlock: Use the mcs_spinlock helper functions for MCS queuing Waiman Long
2013-11-12 14:48 ` Waiman Long
2013-11-12 14:48 ` [PATCH v6 5/5] qrwlock: Use smp_store_release() in write_unlock() Waiman Long
2013-11-12 14:48 ` 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=20131118184644.GC29695@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=Waiman.Long@hp.com \
--cc=akpm@linux-foundation.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=peterz@infradead.org \
--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=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).