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 11:42:35 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Sedat Dilek <sedat.dilek@...il.com>,
	Waiman Long <waiman.long@...com>,
	Ingo Molnar <mingo@...nel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	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>,
	Andi Kleen <andi@...stfloor.org>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>
Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless
 update of refcount

On Fri, Aug 30, 2013 at 9:12 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Now I know this isn't going to be popular, but I'll suggest it anyway.
> What about only implementing the lockref locking when CPUs are greater
> than 7, 7 or less will still use the normal optimized spinlocks.

I considered it. It's not hugely difficult to do, in that we could
make it a static key thing, but I'd actually rather make it depend on
some actual user-settable thing than on some arbitrary number of
cpu's.

See the CMPXCHG_LOOP() macro in lib/lockref.c: it would be easy to
just enclose the whole thing in a

    if (static_key_enabled(&cmpxchg_lockref)) { .. }

and then it could be enabled/disabled at will with very little
performance downside. And I don't think it's necessarily a bad idea.
The code has a very natural "fall back to spinlock" model.

THAT SAID.

Even though uncontended spinlocks are faster than a cmpxchg, under any
real normal load I don't think you can necessarily measure the
difference. Remember: this particular benchmark does absolutely
*nothing* but pathname lookups, and even then it's pretty close to
noise. And the biggest disadvantage of cmpxchg - the fact that you
have to read the cache line before you do the r-m-w cycle, and thus
might have an extra cache coherency cycle - shouldn't be an issue for
the dentry use when you don't try to hit the same dentry over and over
again, because the code has already read the dentry hash etc.

So I'm not sure it's really worth it. It might be interesting to try
that static_key approach simply for benchmarking, though. That way you
could benchmark the exact same boot with pretty much the exact same
dentry population, just switch the static key around and run a few
path-intensive benchmarks.

If anybody is willing to write the patch and do the benchmarking (I
would suggest *not* using my idiotic test-program for this), and then
send it to me with numbers, that would be interesting...

                   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/

Powered by blists - more mailing lists