linux-kernel - Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

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]

Date:	Fri, 14 Nov 2008 13:12:17 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Alexander van Heukelum <heukelum@...lshack.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>, lguest@...abs.org,
	jeremy@...source.com, Steven Rostedt <srostedt@...hat.com>,
	Mike Travis <travis@....com>
Subject: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

On Friday 14 November 2008 12:20, H. Peter Anvin wrote:
> Nick Piggin wrote:
> > I heard from an Intel hardware engineer that Nehalem has some
> > really fancy logic in it to make locked instructions "free", that
> > was nacked from earlier CPUs because it was too costly. So obviously
> > it is taking a fair whack of transistors or power for them to do it.
> > And even then it is far from free, but still seems to be one or two
> > orders of magnitude more expensive than a regular instruction.
>
> Last I heard it was still a dozen-ish cycles even on Nehalem.

Right -- that's their definition of "free", and even comes after
they seem to have put a large amount of effort into it. So they
are still expensive.


> > IMO, we shouldn't stop bothering about LOCK prefix in the forseeable
> > future.
>
> Even if a CPU came out *today* that had zero-cost locks we'd have to
> worry about it for at least another 5-10 years.  The good news is that
> we're doing pretty good with it for now, but I don't believe in general
> we can avoid the fact that improving LOCK performance helps everything
> when you're dealing with large numbers of cores/threads.

There is a balance, though. And that is going to depend on what other
low hanging fruit the CPU has eaten, and what the ratio of lock
instructions is on the target workload. So it's always preferable to
reduce their number. (by definition they will always be more difficult
for the CPU to execute)
--
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/