linux-kernel - Re: [PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

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:	Wed, 10 Apr 2013 08:46:24 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Robin Holt <holt@....com>
Cc:	Ingo Molnar <mingo@...nel.org>, Waiman Long <Waiman.Long@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Dave Jones <davej@...hat.com>,
	Clark Williams <williams@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Davidlohr Bueso <davidlohr.bueso@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

On Wed, Apr 10, 2013 at 7:09 AM, Robin Holt <holt@....com> wrote:
> On Mon, Apr 08, 2013 at 07:38:39AM -0700, Linus Torvalds wrote:
>>
>> I forget where we saw the case where we should *not* read the initial
>> value, though. Anybody remember?
>
> I think you might be remembering ia64.  Fairly early on, I recall there
> being a change in the spinlocks where we did not check them before just
> trying to acquire.

No, I think I found the one I was thinking of. It was the x86-32
version of atomic64_xchg() and atomic64_add_return(). We used to
actually read the old value in order to make the cmpxchg succeed on
the first try most of the time, but when it was cold in the cache that
actually hurt us. We were better off just picking a random value as
our first one, even if it resulted in the loop triggering, because for
the cold-cache case that avoids the unnecessary "bring in in shared
for the read, just to write to it later".

Commits 3a8d1788b37435baf6c296f4ea8beb4fa4955f44 and in particular
824975ef190e7dcb77718d1cc2cb53769b16d918.

Of course, a good OoO CPU would see the write happening later to the
same address, and bring things in for exclusive access immediately.
And it's possible that newer CPU's do that, but we did see this as
being an issue.

            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/