Re: Another security vulnerability

On 3/29/24 10:15 AM, Scott Lurndal wrote:

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

On 3/28/24 3:59 PM, MitchAlsup1 wrote:

[snip]

This is the tidbit that prevents doing prefetches at/in the DRAM controller.
The address so fetched needs translation !! And this requires dragging
stuff over to DRC that is not normally done.

>
With multiple memory channels having independent memory
controllers (a reasonable design I suspect), a memory controller
may have to send the prefetch request to another memory controller
anyway.

 Which is usually handled by the LLC when the address space is
striped across multiple memory controllers.

For data-dependent (pointer chasing) prefetching, one would like
for the prefetch to start as soon as the data was available. For a
cache miss that would be in the memory controller. Having to do
address translation can be inconvenient even for LLC.

  

Busses on cores are reaching the stage where an entire cache line
is transferred in 1-cycle. With such busses, why define anything
smaller than a cache line ?? {other than uncacheable accesses}

>
The Intel research chip was special-purpose targeting
cache-unfriendly code. Reading 64 bytes when 99% of the time 56
bytes would be unused is rather wasteful (and having more memory
channels helps under high thread count).

 Given the lack of both spatial and temporal locality in that
workload, one wonders if the data should be cached at all.

Most of the data was intended not to be cached. Instructions and
stack would still have spatial locality and some temporal
locality.

However, even for a "general purpose" processor, "word"-granular
atomic operations could justify not having all data transfers be
cache line size. (Such are rare compared with cache line loads
from memory or other caches, but a design might have narrower
connections for coherence, interrupts, etc. that could be used for
small data communication.)

 So long as the data transfer is cachable, the atomics can be handled
at the LLC, rather than the memory controller.

Yes, but if the width of the on-chip network — which is what Mitch
was referring to in transferring a cache line in one cycle — is
c.72 bytes (64 bytes for the data and 8 bytes for control
information) it seems that short messages would either have to be
grouped (increasing latency) or waste a significant fraction of
the potential bandwidth for that transfer. Compressed cache lines
would also not save bandwidth. These may not be significant
considerations, but this is an answer to "why define anything
smaller than a cache line?", i.e., seemingly reasonable
motivations may exist.