内存延迟是否受CPU频率的影响？它是内存控制器进行内存电源管理的结果吗？

Question

我基本上需要一些帮助来解释/确认一些实验结果。

基础理论

关于DVFS的论文中表达的一个常见想法是执行时间具有片上和片外组件。执行时间的片上组件与CPU频率成线性关系，而片外组件保持不受影响。

因此，对于CPU绑定应用程序，CPU频率和指令退出率之间存在线性关系。另一方面，对于经常错过高速缓存并且必须经常访问DRAM的内存绑定应用程序，关系应该是仿射的（一个不仅仅是另一个的倍数，你还必须添加一个常量）。 / p>

实验

我正在做实验，研究CPU频率如何影响不同内存限制水平下的指令退出率和执行时间。

我在C中编写了一个遍历链表的测试应用程序。我有效地创建了一个链表，其各个节点的大小等于缓存行的大小（64字节）。我分配了大量内存，这是缓存行大小的倍数。

链表是循环的，以便最后一个元素链接到第一个元素。此外，该链表随机遍历分配的内存中的高速缓存行大小的块。访问分配的内存中的每个缓存行大小的块，并且不会多次访问任何块。

由于随机遍历，我认为硬件不应该使用任何预取。基本上，通过遍历列表，您有一系列内存访问，没有步幅模式，没有时间局部性，也没有空间局部性。此外，因为这是一个链接列表，所以只有一个内存访问才能在前一个内存访问完成之前开始。因此，存储器访问不应该是可并行化的。

当分配的内存量足够小时，除了初始预热之外，您应该没有缓存未命中。在这种情况下，工作负载实际上受CPU限制，并且指令退出率与CPU频率非常干净地扩展。

当分配的内存量足够大（大于LLC）时，您应该错过缓存。工作负载受内存限制，指令退出率也不应随CPU频率而扩展。

基本实验设置类似于此处描述的设置： ＆＃34; Actual CPU Frequency vs CPU Frequency Reported by the Linux "cpufreq" Subsystem＆＃34;

上述应用程序反复运行一段时间。在持续时间的开始和结束时，对硬件性能计数器进行采样，以确定在该持续时间内退出的指令数。也测量持续时间的长度。平均指令退休率是以这两个值之间的比率来衡量的。

使用＆＃34; userspace＆＃34;在所有可能的CPU频率设置中重复此实验。 Linux中的CPU频率调控器。此外，如上所述，对CPU绑定的情况和内存限制的情况重复实验。

结果

以下两个图分别显示了CPU绑定案例和内存限制案例的结果。在x轴上，CPU时钟频率以GHz为单位指定。在y轴上，指令退出率以（1 / ns）指定。

放置标记物以重复上述实验。该行显示如果指令退出率以与CPU频率相同的速率增加并通过最低频率标记，结果将是什么。

---

CPU绑定案例的结果。

---

内存限制案例的结果。

---

结果对于CPU绑定的情况有意义，但对于内存限制的情况则没有那么多。内存限制的所有标记都落在预期的行之下，因为指令退出率不应该以与内存绑定应用程序的CPU频率相同的速率增加。标记似乎落在直线上，这也是预期的。

但是，随着CPU频率的变化，指令退出率似乎会发生阶段性变化。

问题

导致指令退休率的步骤变化的原因是什么？我能想到的唯一解释是内存控制器以某种方式通过内存请求速率的变化来改变内存的速度和功耗。 （随着指令退出率的增加，内存请求的速率也应该增加。）这是正确的解释吗？

Answer 1

您似乎具有预期的结果 - 对于cpu绑定程序的大致线性趋势，以及对于内存限制情况（受cpu影响较小）的浅（呃）仿射结果。您将需要更多数据来确定它们是否是一致的步骤，或者它们是否 - 我怀疑 - 大多数是随机抖动，具体取决于列表的“好”程度。

cpu时钟将影响总线时钟，这将影响时序等等 - 不同时钟总线之间的同步对于硬件设计人员来说总是具有挑战性。你的步骤的间距有趣地是400 Mhz但是我不会从中得到太多 - 通常，这种东西太复杂和具体 - 硬件依赖于正确分析没有内部控制器使用的“内部”知识等。

（请画出最合适的线条）