Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Paul A. Clayton" <paaronclayton@gmail.com>
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Thu, 13 Jun 2024 18:52:13 -0400
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <v4ft6v$2g612$1@dont-email.me>
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>
 <3a691dbdc80ebcc98d69c3a234f4135b@www.novabbs.org>
 <k58h6jlvp9rl13br6v1t24t47t4t2brfiv@4ax.com>
 <5a27391589243e11b610b14c3015ec09@www.novabbs.org>
 <jqgaO.1934$WaKd.92@fx41.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Jun 2024 00:52:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9bc529aa01f938c22a707fb859b26e71";
	logging-data="2627618"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18iRQaNEMwi1wYo9M8FL/Bl11uXPH6O534="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.0
Cancel-Lock: sha1:EbjmY0GprwktMVvzLRA76bZbrJk=
In-Reply-To: <jqgaO.1934$WaKd.92@fx41.iad>
Bytes: 4513

On 6/12/24 8:22 AM, EricP wrote:
> MitchAlsup1 wrote:
>> John Savard wrote:
>>
>>
>>> After all, RowHammer is caused by multiple rapid-fire accesses 
>>> to the
>>> same address, or to related addresses, in memory.
>>
>> Yes, the write buffer in my DRAM controller is the L3 cache. 
>> Modified
>> data in the L3 migrates towards DRAM as DRAM cycles permit, but 
>> there
>> is no way to cause a line to be continuously be written into DRAM.
>> If a modified line has migrated to DRAM, and it gets modified again
>> in the L3, that 2nd write will not be performed until a refresh 
>> cycle
>> on that DRAM is performed.
>>
>> Thus if one tries to RowHammer My 66000 DRAM, DRAM gets refresh 
>> cycle
>> between each write.
> 
> What does it do if L3 receives more writes than it has ways in a row,
> does it stall evicts from L2?
> 
> Lets say L3 is 4 way assoc and all four in a L3 row been updated,
> then a 5th way in that same row is written from L2.
> L3 has no place to hold that 5th way and it can't evict one
> of the other 4 ways because that could cause rowhammer.

Sidenote: With skewed associativity, one can use cuckoo/elbow
caching, i.e., select a block for eviction from another "set"
(which could then select a block from a different "set" to
retain the block). (I prefer the term "cuckoo cache" because
it uses the same mechanism as "cuckoo hash", though "The Elbow
Cache: A Power-Efficient Alternative to Highly Associative Caches"
(2003, Mathias Spjuth et al.) may be the first publication
using the mechanism for processor caches. The concept is
sufficiently rarely referenced that no name is widely known.)

Skewed associativity already has a different concept of "set";
cuckoo replacement presents even more diverse replacement
options.

("Overlaid" skewed associativity would seem to increase the
chance that a better victim could be found sooner. Overlaid
skewed associativity — my term — was proposed for variable
page size TLBs in "Concurrent Support of Multiple Page Sizes On
a Skewed Associative TLB" (André Seznec, 2003).)

With more tags than blocks and at least some
indirection (e.g., "The V-Way Cache : Demand-Based Associativity 
via Global Replacement", Moinuddin K. Qureshi et al., 2005), the
effective associativity could be further increased.

(Victim caches are a more widely known way of "extending"
associativity.)

> Seems to me that all it can do is stall the 5th write from L2 until
> DRAM refresh rolls around and re-enables one of the pending L3 
> writes,
> which would back up victim evicts from L2.
> Or maybe L3 has a small fully assoc emergency overflow buffer,
> but still that could fill up too.

Eventually writes would be stalled due to memory bandwidth even
with no avoidance of row hammering. Avoiding row hammer would
seem to cause extra delays in some cases, but that seems better
than changing data. (Quality of service/resource allocation
budgets might be important for avoiding denial of service given
resource sharing.)