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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20071016124916.GE1000@ff.dom.local>
Date:	Tue, 16 Oct 2007 14:49:16 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	david@...g.hm
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, Oct 16, 2007 at 02:14:17AM -0700, david@...g.hm wrote:
...
> 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.

It's a good point to always consider when you analyze how something
new should work if it's used with older programs too. But with newer
things like SMP or multithreading they probably have more choice, and
you can only guess what it's done 'officially'.

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

The failure of an architecture doesn't mean all specific new
technologies used in itanium were failure too, so they could be back
when needed (and nothing better in reserve) yet.

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

I don't think 'not breaking' is much problem here, rather how to use
all new features (which you seem to ignore a bit) to get maximum of
performance without breaking older things. Or, like current problem:
go rational and remove useless (acording to new specs) things, even
without performance gain, or stay 'safe'?

Jarek P.
-
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/