linux-kernel - Re: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock

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 linux-cve-announce 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:	Mon, 18 Nov 2013 10:11:48 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Waiman Long <Waiman.Long@...com>
Cc:	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" <linux-arch@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.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>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	George Spelvin <linux@...izon.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Aswin Chandramouleeswaran <aswin@...com>,
	Scott J Norton <scott.norton@...com>
Subject: Re: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock

On Tue, Nov 12, 2013 at 6:48 AM, Waiman Long <Waiman.Long@...com> wrote:
> By default, queue rwlock is fair among writers and gives preference
> to readers allowing them to steal lock even if a writer is
> waiting. However, there is a desire to have a fair variant of
> rwlock that is more deterministic. To enable this [..]

Is there really any point in having the option for unfair at all?

>From your timings, it looks like the unfair locks are more expensive
for the writer side, but since pretty much the whole point of rwlocks
is when readers are the common case, I don't think we care.

And I'm not at all convinced we want the complexity of two different
kinds of rwlocks with different semantics and extra code for said
semantics..

Your *original* fair rwlocks were unusable, since they didn't allow
for the irq semantics that most users need, but afaik your current
version always makes an irq/bh-context reader work even when the lock
is otherwise trying to be fair, so this whole dual behavior seems to
be largely pointless.

No?

                        Linus
--
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/