Path: ...!eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Tue, 11 Jun 2024 08:54:16 +0300
Organization: Tidorum Ltd
Lines: 37
Message-ID: <lcq749F7sotU1@mid.individual.net>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com>
 <h0ib6j576v8o37qu1ojrsmeb5o88f29upe@4ax.com>
 <2024Jun9.185245@mips.complang.tuwien.ac.at>
 <38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com>
 <2024Jun10.091648@mips.complang.tuwien.ac.at>
 <o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net o4i3odJw8uuoWIOjzWfpoQsERaGnAGYJIaMeiplP0wsnHQ2iTR
Cancel-Lock: sha1:F5lMhHPW6q55SklUjuUFU/Xxpog= sha256:GAaC22QMZP1SzeoV7nSHfl66MFCUo6Gv2NONtHTHpQ0=
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com>
Bytes: 2692

On 2024-06-11 2:22, John Savard wrote:
> On Mon, 10 Jun 2024 07:16:48 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
> 
>> John Savard <quadibloc@servername.invalid> writes:
> 
>>> In the case of Spectre, fixing the hardware has a cost in performance.
>>
>> How do you know?
>>
>> Papers on so-called "invisible speculation" schemes have reported
>> slowdowns <10% for the more advanced schemes, with IIRC some even
>> reporting a speedup.
> 
> I've heard claims - especially from Mitch Alsup - that, indeed, all
> one has to do is avoid certain _mistakes_ when designing a pipeline,
> and there's no room for Spectre any more.
> 
> I'm no expert on these things at all, so I don't know that this can't
> be true. But I also don't know that it _is_ true.
> 
> What does Spectre exploit? it exploits the fact that speculative
> execution keeps around data that was fetched into cache by the
> speculative execution of some code that was never supposed to be
> executed. Just in case it might be useful later.
> 
> Obviously, keeping around any data that just happens to be
> accidentally in cache, just in case it might be useful later, does
> have a positive (but likely very slight) effect on performance. 


Not always. If the mistakenly speculated cache-fetch /evicted/ some 
other data from the (finite-sized) cache, and the evicted data are 
needed later on the /true/ execution path, the mistakenly speculated 
fetch has a /negative/ effect on performance. (This kind of "timing 
anomaly" is very bothersome in static WCET analysis.)