linux-kernel - Re: [PATCH v11 0/4] Introducing a queue read/write lock implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 2 Feb 2014 10:03:57 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Waiman Long <waiman.long@...com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
	linux-arch@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michel Lespinasse <walken@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Rik van Riel <riel@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	George Spelvin <linux@...izon.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>, aswin@...com,
	Scott J Norton <scott.norton@...com>
Subject: Re: [PATCH v11 0/4] Introducing a queue read/write lock
 implementation


* Waiman Long <waiman.long@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/