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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091110201602.GA26633@1wt.eu>
Date:	Tue, 10 Nov 2009 21:16:02 +0100
From:	Willy Tarreau <w@....eu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Avi Kivity <avi@...hat.com>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@....cz>,
	Matteo Croce <technoboy85@...il.com>,
	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 12:01:47PM -0800, H. Peter Anvin wrote:
> On 11/10/2009 11:50 AM, Avi Kivity wrote:
> >>
> >> Consider SSE3, for example.  Why should the same concept not apply to
> >> SSE3 instructions as to CMOV?
> > 
> > Because then user programs would run 20x or more slower than the user 
> > expects.  Better to terminate early (and teach userspace how to choose 
> > the instruction subset correctly).
> > 
> 
> I picked the example carefully: SSE3 is a small set of instructions
> which probably aren't used very heavily.  In that sense, it has
> *exactly* the same properties as CMOV - if you have the source, you're
> better off recompiling, but it *might* help you if you happen to only
> have a binary.
> 
> What I want people to understand is that this is a *huge* rathole, and
> it doesn't have any obvious bottom that I can see.

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
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
any program to have at least one or two inside, making it incompatible
with a given processor, and are almost obvious to implement too.

SSE*/3dnow* would be much much harder and would only serve very few
programs, and serve them badly because when they're used, it would
be intensive.

I personally am not against being able to emulate every optional
instruction, quite the opposite instead. It's just that if in order
to do this, we add cost to the other obvious ones, we lose what we
expected to win (simplicity and efficiency).

Regards,
Willy

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