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] [day] [month] [year] [list]

Message-ID: <401F72D6D1DFE3499766D25AA4EED18A35440103@G6W2503.americas.hpqcorp.net>
Date:	Tue, 19 Nov 2013 04:33:09 +0000
From:	"Long, Wai Man" <waiman.long@...com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>
Subject: RE: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock

Sorry for the late reply.

The presence of the unfair option as default is largely due to fixing the recursive read lock in interrupt handler problem. You are right that it is no longer a valid reason now. 

An unfair lock may have a better performance characteristics, especially for a highly contended lock. Other than that, I have no other reason to keep an unfair option. I don't mind taking out the unfair option and make the fair qrwlock the default. It does simplify the code. I will send out an updated patchset with only the fair qrwlock.

Thank for suggestion.
-Longman

-----Original Message-----
From: linus971@...il.com [mailto:linus971@...il.com] On Behalf Of Linus Torvalds
Sent: Monday, November 18, 2013 1:12 PM
To: Long, Wai Man
Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Arnd Bergmann; linux-arch@...r.kernel.org; the arch/x86 maintainers; Linux Kernel Mailing List; Peter Zijlstra; Steven Rostedt; Andrew Morton; Michel Lespinasse; Andi Kleen; Rik van Riel; Paul E. McKenney; Raghavendra K T; George Spelvin; Tim Chen; Chandramouleeswaran, Aswin; Norton, Scott J
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