从 GEM5 获取物理地址跟踪 [英] Obtaining physical address trace from GEM5

问题描述

我一直在尝试提取应用程序访问的物理地址以分析行命中.

I've been trying to extract physical address accessed by the application in order to analyze the row hits.

这样做时，我关注了此页面 由于版本变化而变化很小.

In doing so, I followed this page with little variation due to version change.

我将 CacheConfig.py 修正为:

I fixed CacheConfig.py as:

system.monitor2 = CommMonitor()
system.monitor2.trace = MemTraceProbe(trace_file = "CT_mon2.trc.gz")
system.monitor2.slave = system.l2.mem_side

system.membus.slave = system.monitor2.master
system.l2.cpu_side = system.tol2bus.master

并运行代码:

build/X86/gem5.opt --debug-flag=CommMonitor configs/example/se.py --caches --l2cache --l2_size=2MB --mem-type=DDR4_2400_16x4 -c        tests/test-progs/mm/bin/x86/linux/mm --cpu-type=TimingSimpleCPU

mm 是来自简单矩阵乘法的二进制:

The mm is a binary from a simple matrix multiplication:

// C program to multiply two square matrices. 
#include <stdio.h>
#define N 4 

// This function multiplies mat1[][] and mat2[][], 
// and stores the result in res[][] 
void multiply(int mat1[][N], int mat2[][N], int res[][N])
{
    int i, j, k;
    for (i = 0; i < N; i++)
    {
        for (j = 0; j < N; j++)
        {
            res[i][j] = 0;
            for (k = 0; k < N; k++)
                res[i][j] += mat1[i][k]*mat2[k][j];
        }
    }
}

int main()
{
    int mat1[N][N] = { {1, 1, 1, 1},
                    {2, 2, 2, 2},
                    {3, 3, 3, 3},
                    {4, 4, 4, 4}};

    int mat2[N][N] = { {1, 1, 1, 1},
                    {2, 2, 2, 2},
                    {3, 3, 3, 3},
                    {4, 4, 4, 4}};

    int res[N][N]; // To store result 
    int i, j;
    multiply(mat1, mat2, res);

    printf("Result matrix is \n");
    for (i = 0; i < N; i++)
    {
        for (j = 0; j < N; j++)
        printf("%d ", res[i][j]);
        printf("\n");
    }

    return 0;
}

解码CT_mon2.trc.gz"后，内存轨迹如图:

After decoding the "CT_mon2.trc.gz", the memory trace are shown as:

5,u,15360,64,256,11500
6,u,183808,64,2,101000
5,u,18816,64,256,187000
6,u,183744,64,2,285000
5,u,18880,64,256,357000
6,u,171072,64,3,438000
6,u,171648,64,3,526000
6,u,172032,64,3,601000
6,u,174528,64,3,689000
5,u,18944,64,256,765000

第三个表示物理地址.

让我感到困惑的是u"部分.从解码阶段开始，任何不是 read(r) 或 write(w) 的都被标记为u".

What I'm confusing is the "u" part. From decode stage, whatever that isn't read(r) or write(w) are notated as "u".

在调试过程中，命令重复出现UpgradeFailResp"和ReadCleanReq".

With debugging, commands were repeating with "UpgradeFailResp" and "ReadCleanReq".

我期待读取和写入的跟踪，但我不确定这里发生了什么.

I was expecting a trace with reads and writes, but I'm not sure what is happening here.

谁能告诉我我错过了什么?

Can anyone tell me what am I missing?

或者甚至更好的获取物理地址的方法将是一个巨大的帮助.

Or even better way to obtain physical address will be a huge help.

谢谢，杰利

推荐答案

您会看到超出读取和写入的流量的原因与 CommMonitor 的位置有关.在您的系统中，membus 可能是一致性点，因此您将获得由 l2 缓存生成的各种流量，这些流量用于与其他 l2 缓存(如果存在)的缓存一致性操作.如果您将 CommMonitor 移动到一致性点以下，例如在 membus 和内存控制器之间，您应该只能看到读取和写入流量.

The reason you will see traffic beyond reads and writes has to do with the placement of the CommMonitor. In your system, the membus is likely the point of coherency, so you will get all sorts of traffic generated by the l2 cache that is meant for cache coherency operations with other l2 caches (if they existed). If you move your CommMonitor beneath the point of coherency, e.g. between the membus and and your memory controllers, you should see only read and write traffic.

这篇关于从 GEM5 获取物理地址跟踪的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！