linux-kernel - Re: [rfc][patch 3/3] x86: optimise barriers

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]

Date:	Tue, 16 Oct 2007 02:14:17 -0700 (PDT)
From:	david@...g.hm
To:	Jarek Poplawski <jarkao2@...pl>
cc:	Nick Piggin <npiggin@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Helge Hafting <helge.hafting@...el.hist.no>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...e.de>
Subject: Re: [rfc][patch 3/3] x86: optimise barriers

On Tue, 16 Oct 2007, Jarek Poplawski wrote:

> On Tue, Oct 16, 2007 at 02:50:33AM +0200, Nick Piggin wrote:
>> On Mon, Oct 15, 2007 at 11:10:00AM +0200, Jarek Poplawski wrote:
> ...
>
>>> As a matter of fact it's not natural for me at all. I expected the
>>> other direction, and I still doubt programmers' intentions could be
>>> "automatically" predicted good enough, so IMHO, it's not for long.
>>
>> Really? Consider the consequences if, instead of releasing this latest
>> document tightening consistency, Intel found that out of order loads
>> were worth 5% more performance and implemented them in their next chip.
>> The chip could be completely backwards compatible, but all your old code
>> would break, because it was broken to begin with (because it was outside
>> the spec).
>
> I've different opinion on this: I expect any spec to describe current
> implementation. Before issuing new models any changes of
> implementation should be made public with proper margin of time. Then
> system could be optimally adjusted to a real hardware, instead of
> planned only, but possibly never realized (plus doing such not used
> things with old means is usually more costly: lock vs. lfence). There
> is still problem of specs' completness: there are probably often some
> things unspecified which could brake on a new model, so never 100%
> guarantee anyway.

what you don't realize is that Intel (and AMD) have built their business 
on makeing sure that their new CPU's run existing software with no 
modifications, (and almost always faster then the old versions). remember 
that for most of the world, getting the software modified would mean 
buying a new version, if the vendor bothered to make a different version 
for the new chip.

if they required everyone to buy new software to use a new chip it 
wouldn't work well. In fact Intel tried to do exactly withat with the 
itanium and it has been a spectacular failure (or t the very least, not a 
spectacular sucess)

>> IMO Intel did exactly the right thing from an engineering perspective,
>> and so did Linux to always follow the spec.
>
> But, if you follow the spec - you don't follow the spec! Why do you
> ignore so much this part of Intel's spec:
>
> "This document contains information which Intel may change at any
>  time without notice. Do not finalize a design with this information."
>
> Maybe it's a real Intel intention and not for lawyers only? (Btw, it
> seems we have an example.)

in theory they could change anything at any time, in practice if they 
break old software they won't sell the chips, so the modifications tend to 
be along the lines of this one, adding detail to the specifications so 
that programmers can get more performance.

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