linux-kernel - Re: i686 quirk for AMD Geode

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: <40101cc30911101401o79a62066qf87be897abbb354e@mail.gmail.com>
Date:	Tue, 10 Nov 2009 23:01:26 +0100
From:	Matteo Croce <technoboy85@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Willy Tarreau <w@....eu>, "H. Peter Anvin" <hpa@...or.com>,
	Avi Kivity <avi@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Sven-Haegar Koch <haegar@...net.de>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: i686 quirk for AMD Geode

On Tue, Nov 10, 2009 at 9:54 PM, Pavel Machek <pavel@....cz> wrote:
> Hi!
>
>> Indeed, but there is a difference between [cmpxchg, bswap, cmov, nopl]
>> on one side and [sse*] on the other : distros are built assuming the
>> former are always available while they are not always. And the
>> distro
>
> Well, fix the distros...

$ objdump -d libflashplayer.so |grep cmov -c
10

and ask the companies to fix their binaries too?

>> which make the difference have to provide an dedicated build for earlier
>> systems just for compatibility. SSE*, 3dnow* etc... are only used by a
>> handful of media players/converters/encoders which are able to detect
>> themselves what to use and already have the necessary fallbacks because
>> these instruction sets vary too much between processors and vendors.
>>
>> One could argue that cmpxchg/bswap/xadd are supported by 486 and that
>> implementing them for 386 is almost useless now (though it costs almost
>> nothing to provide them, I did a few years ago).
>>
>> CMOV/NOPL are rarely used, thus have no reason to cause a massive
>> performance drop, but are frequent enough (at least cmov) for almost
>
> *One* CMOV in the inner loop will make your performance go down 20x.

Still better than a browser crashing for a SIGILL
--
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/