linux-kernel - Re: [PATCH RFC ticketlock] Auto-queued ticketlock

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:	Fri, 14 Jun 2013 08:37:05 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Waiman Long <waiman.long@...com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Davidlohr Bueso <davidlohr.bueso@...com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	"?????????" <laijs@...fujitsu.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Josh Triplett <josh@...htriplett.org>, niv@...ibm.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	David Howells <dhowells@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Darren Hart <darren@...art.com>,
	"Fr??d??ric Weisbecker" <fweisbec@...il.com>,
	Silas Boyd-Wickizer <sbw@....edu>
Subject: Re: [PATCH RFC ticketlock] Auto-queued ticketlock

On Fri, Jun 14, 2013 at 8:00 AM, Waiman Long <waiman.long@...com> wrote:
> On 06/12/2013 08:59 PM, Linus Torvalds wrote:
>>
>> Ho humm.. interesting. I was talking about wanting to mix atomics and
>> spinlocks earlier in this thread due to space constraints, and it
>> strikes me that that would actually help this case a lot. Having the
>> dentry count mix d_lock and the count in one word would allow for
>> atomic ops like "increment if not locked", and we'd avoid this whole
>> race entirely..
>>
>> Something like "low bit of count is the lock bit" would end up being
>> lovely for this case. Of course, that's not how our spinlocks work ..
>>
>>                Linus
>
>
> I have created another patch to do exactly the "increment if not locked"
> operation as suggested. It did help a lot. See the patch below for more
> information. Any additional comment will be appreciated.

Hmm. This is interesting and proves the concept, and the numbers look
very promising.

The patch is not mergable, though, since it clearly depends on the
spinlock/d_count fitting in a u64, which is normally true, but not the
case of debugging locks etc, we'd need to generalize and fix the whole
concept of "refcount+lock".

Generalizing it might be a good idea anyway, since there are other
cases of "atomic_dec_and_lock()" etc behaviours where we might want to
have these kinds of extended lock+count shenanigans.

I also do wonder if we could perhaps fit both in 32-bits, and just not
use the "real" spinlocks at all, but use a bitlock in the low (or
high) bit of the refcount. We do that in some other places - we'd
potentially lose lockdep etc, and we'd lose some of the other good
parts of spinlocks (fairness yadda yadda), but *if* we can reduce
contention enough that it works out, maybe it would be worth it.

So this doesn't look like 3.11 material, but the numbers certainly
make it look very promising, so with some more work on it ...

                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/