Fundamental idea of this memory denial of service simulation using array copy? I am just watching this lecture Computer Organization - Introduction And Basics where
the lecturer mentions about using a simple code to demonstrate how memory denial of service can be simulated in DRAM by exploiting an optimzation DRAM Controller does internally. The optimization seems to be that DRAM Controller serves the same row buffer whenever possible for the instructions coming to the pipeline and so it can be exploited by sending instructions that use a very localized data giving it priority.

//initialize large arrays A and B

for(j=0; j&lt;n; j++)
{
index = j*linesize;
A[index] = B[index]
}


I just wanted to understand the fundamental concept of this approach. The Lecturer says that the above code would copy an Array from B to A. However I am not sure how it actually would copy an Array from B to A because it doesn't seem to go over each index item.

My real doubt, assuming that this is just a simulation code which copies some part of B to A for demonstration purpose and that linesize is just a large value to make a cache miss, is if the central idea behind this something like:

a) chose an index that is sufficiently wide apart so that a       cache miss happens

b) yet the memory is close enough for it to be in the same row for the memory controller to serve from the same row buffer

Which is needed to simulate this DoS (denial of service) scenario?

Quoting from the paper that explains this in depth Memory Performance Attacks - Denial Of Service In Multi Core Systems


  The arrays in stream are sized such that they are much larger than the
  L2 cache on a core. Each array consists of 2.5M 128-byte elements. Stream (Figure 3(a)) has very high row-buffer locality since
  consecutive cache misses almost always access the same row (limited
  only by the size of the row-buffer).
The idea is that this code does not copy the complete array, but due to the design of the memory hardware it takes just as much time as if it would. Reading and writing a single byte will move a whole cache line. So the code reading and writing does very little work, but causes the memory subsystem to perform a whole lot of work.