linux-kernel - Re: [tip:x86/asm] x86: Prefer TZCNT over BFS

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]

Message-ID: <50575855.8040308@zytor.com>
Date:	Mon, 17 Sep 2012 10:05:25 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Ingo Molnar <mingo@...nel.org>, Jan Beulich <JBeulich@...e.com>,
	tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: Re: [tip:x86/asm] x86: Prefer TZCNT over BFS

On 09/17/2012 10:00 AM, Linus Torvalds wrote:
\>
> As Jan already pointed out, I really want more than that.
> 
> The *conditions* for selecting X86_TZCNT have to be sane too.
> 
> I really think that "32-bit generic kernel" is totally and completely
> a wrong choice for enabling this. A 32-bit setup has exactly two
> relevant cases:
> 
>  - old CPU's that don't support TZCNT anyway
>  - new CPU's where the user doesn't care about performance (things
> like HIGHMEM will have killed it much more than TZCNT etc ever will)
> 
> and in neither case is the TZCNT instruction relevant.
> 
> Even for the 64-bit case, I really don't see why "generic" should pick
> it up either. The fact that we don't have many CPU optimization
> choices for x86-64 is not an excuse to then overload "generic" with
> that kind of choice, I think.
> 
> So I really objected not only to the ugly and unreadable conditionals,
> I objected to the criteria for them too.
> 

Honestly, I don't see a reason to not do this unconditionally.  On
anything but (pre-686-era) extremely old CPUs the cost of the extra
prefix is zero.  On the really old CPUs the cost of the BSF instruction
will dwarf the penalty cycle for the extra prefix, so the whole
mechanism around doing it conditionally seems pointless.

	-hpa


--
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/