Memory contention model (example)

Stuttgart, Germany, July 9th 2019
Post Reply
Posts: 9
Joined: Wed Apr 20, 2016
Location: @Unimore

Memory contention model (example)

Post by Nacho_S » Wed Mar 06, 2019

In the challenge we ask to derive a memory contention model when more than one CPU core and/or the GPU is accessing memory
at the same time. Taking into account that:
  • A task mapped to run on the GPU, needs offloading data that is acquired through the copy engine (GPU CE). Also, a GPU kernel can output data to be copied back to the host.
  • CPU tasks are modeled as with a Read/Compute/Write semantic, with "Read" and "Write" being 100% memory bounded operations, and
  • GPU CE, A57 and Denver have a significantly different memory bandwidth, latencies and sensitivity to memory interference.

According to the following references that measure memory impact on interference: ... er=8247615 ... tforms.pdf

The idea is that the length of memory phases (read and write) depends on how many other memory controller clients
are accessing main memory at the same time.

Let us suppose the following ideas for modeling interference:
We are given a taskset of CPU and GPU tasks.
Size of buffers to read and to write is known in advance and it is fixed for every instance of the periodic job.
From the GPU side we only consider interference from the Copy Engine data movements (modeled in amalthea as "runnables").
A GPU CE data movement is a 100% memory bound runnable.
Every memory access is modeled as sequential access patterns.

The model we derive from the previously cited literature is the following and it is used to describe what happens to read/write latencies
when more than one CPU core is accessing main memory at the same time.
Also, the following model accounts for increasing latencies for GPU CE activity during the observed time window.

For CPUs:
Lat(CPUtype,cacheLine)[ns] = baseline(CPUtype) + K(CPUtype)*#C + sGPU(CPUtype)*bGPU

Lat(x,y) = time needed to read or write a cacheLine (64B) from main memory to CPU registers.
CPUtype = Observed CPU core; A57 or Denver
baseline = time taken to read or write a cacheLine (64B) from main memory to CPU registers in isolation (no interference).
baseline(A57) = 20 ns
baseline(Denver) = 8 ns

K(CPUtype) = increase in latency operated by a single interfering core. Do note: it does not matter if the interfering core is denver or A57: this number only depends on the observed CPU core (CPUtype)
K(A57) = 20 ns
K(Denver) = 2 ns
#C = number of interfering cores. Range from 0 to 5 (as one core is the observed CPU core. 0 means no interference from other CPUs)

sGPU = sensibility to GPU CE activity. This represents an increase in latencies if the GPU is performing operations on the copy engine.
sGPU(A57) = 100 ns
sGPU(Denver) = 20 ns

bGPU = boolean. 1: if the GPU is operating the copy engine, 0 otherwise.

for GPU Copy engine:
Lat(memcpy,64B) = GPUbaseline + 0.5*#C

Lat(memcpy,64B) = Time taken to transfer 64B using the copy engine (cudaMemcpy)
GPUbaseline = 3 ns. Time taken to transfer 64B using the copy engine with no interfering CPUs
Each core active in the same time window of the CE operation increases the baseline by half a nanosecond.

Numerical Example:
A task mapped on a A57 core has a memory footprint (read) of 128B.
If no other CPU is accessing memory (#C=0)
and if the GPU CE is idle (bGPU=0),
then the time necessary to perform the read operation of the working set size is:
( 128/cacheLine*Lat(A57,cacheLine) = 2*20 = 40 ns ).
If one core is active (does not matter if denver or A57):
(128/cacheLine*Lat(A57,cacheLine) = 2*(20 + 20*1 + 0) = 80 ns)
And this would increase to 280 ns if the GPU CE was active for the whole time of this memory phase.

Please let us know if you have any further question.

Nacho & Nicola

Post Reply