From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <waiman.long@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
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: Sun, 2 Feb 2014 10:03:57 +0100 [thread overview]
Message-ID: <20140202090357.GA1006@gmail.com> (raw)
In-Reply-To: <52EC110D.4030509@hp.com>
* Waiman Long <waiman.long@hp.com> wrote:
> How about making the selection of MCS or ticket queuing either user
> configurable or depending on the setting of NR_CPUS, NUMA, etc?
No!
There are lots of disadvantages to adding such CONFIG_NUMA Kconfig
variants for locking primitives:
- an doubling of the test matrix
- an doubling of the review matrix and a halving of effective review
capacity: we've just about go the capacity to review and validate
patches like this. Splitting out a 'only NUMA cares' variant is a
non-starter really.
- but most importantly, there's absolutely no reason to not be fast
on 128 CPU systems in the low contended case either! Sacrificing
the low contended case with 'on 128 CPU systems it is the contended
path that matters' is an idiotic argument.
Essentially the only area were we allow Kconfig dependencies are
unyielding physical forces: such as lots of CPUs needing a wider CPU
mask.
As Peter said it, the right solution is to fix the contended case. If
that also happens to speed up or better organize the uncondended code
then that's good, but it should not make it worse.
Thanks,
Ingo
next prev parent reply other threads:[~2014-02-02 9:04 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
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 [this message]
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=20140202090357.GA1006@gmail.com \
--to=mingo@kernel.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=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=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).