linux-kernel - Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

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, 30 Aug 2013 09:16:12 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Waiman Long <Waiman.Long@...com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Jeff Layton <jlayton@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>,
	Michael Neuling <michael.neuling@....ibm.com>
Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless
 update of refcount


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > BTW. Do you have your test case at hand ?
> 
> My test-case is a joke. It's explicitly *trying* to get as much 
> contention as possible on a dentry, by just starting up a lot of threads 
> that look up one single pathname (the same one for everybody). It 
> defaults to using /tmp for this, but you can specify the filename.

Waiman's tests seemed to use sufficiently generic and varied workloads 
(AIM7) and they showed pretty nice unconditional improvements with his 
variant of this scheme, so I think testing with your simple testcase that 
intentionally magnifies the scalability issue is 100% legit and may in 
fact help tune the changes more accurately, because it has less inherent 
noise.

And that was on a 80 core system. The speedup should be exponentially more 
dramatic on silly large systems. A nicely parallel VFS isn't a bad thing 
to have, especially on ridiculously loud hardware you want to run a 
continent away from you.

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/