linux - perf stat 周期数和频率缩放

Question

我一直在使用 perf stat 和 cpufreq-set 在 odroid-xu3 上做一些小实验，这是一个带有 Exynos 芯片(A7 的异构处理器)的嵌入式设备和 A15 ARM 内核)。我使用 BLAS lvl3 基准测试来运行我的实验，并且我一直使用 taskset 实用程序将任务固定到 A15 内核。我也仔细检查了它是一个单线程实现。

希望在高频率或低频率下运行时的周期数应该相同，但我可以看到一个小的变化，例如分别在 400MHz、1000MHz 和 1600MHz 下运行 GEMM 内核(矩阵乘法，100 次运行)我得到结果如下:

7166620830 cycles
17.923790714 seconds time elapsed

7235173436 cycles
7.237463382 seconds time elapsed

7428037080 cycles
4.643897351 seconds time elapsed

您可以看到，即使持续时间与频率也不是真正线性的(这至少与测量的周期数一致......)。一种假设是该任务有点受内存限制，但我在单精度实现中得到了类似的结果……您知道这可能是什么原因吗？

编辑:矩阵有 400 个样本大，我使用环境变量 OPENBLAS_LOOP(openblas 基准)运行它 100 次。我尽量避免运行其他应用程序，我看不出负载为 0%，但已经接近了。你建议我停止一些特别的事情吗？因为它已经是超过 100 次实验的平均值，所以相同频率的变化非常低(<0.1%)，当我改变频率时有大约 4% 的差异，并且对于最高频率它总是有更大的周期数，所以它确实如此看起来不像是更“嘈杂”，它看起来像是在高频发生了其他事情。

Answer 1

CPU 周期不仅用于计算，还用于等待来自内存的数据。 (是的，GEMM 是 BLAS3，在 Roofline model scale 上具有非常好的算术强度和低内存读/写量，但仍然存在内存访问，并且它们的延迟与 CPU 频率不是线性关系。)

不仅要检查 CPU 周期，还要检查应该更稳定的指令计数器(如果为您的 CPU 实现了这个性能计数器)，还要排除内核模式(它可能每 100 Hz 或 300 Hz 有一些周期性任务，如调度程序) 从用 :u 后缀计数:

perf stat -e cycles:u,instructions:u,task-clock:u ./program

(也尝试找到一些为您的核心实现的缓存未命中事件或内存访问事件，也检查核心文档中的原始编码并使用 -e rHHHH 找到的十六进制代码)

当您更改 CPU 时钟频率时，您可能(也可能不会)影响内存 Controller /内存总线频率(这特定于您的 SoC 和启动配置)。 DRAM 内存(可能是“exynos 5422”SoC 中的 LPDDR3)有许多时序是根据内存总线频率计算的，但实际上它们来自真实内存数据库频率和延迟。

大多数时序在绝对 (ns) 时序中将相同(或接近)，但有一个会影响您的代码周期:memory refresh timing - DRAM 内存仅在短时间内保留数据(电荷从数据单元泄漏)，例如每 32 微秒 (ms) 或 64 ms 完全刷新一次(这随高温而变化，通常有两个值 - 低温和高温).使用完整的数据库刷新命令，它将在时间的某些部分无法访问，例如 2% 或 5%(我没有确切的值)。

更改 CPU 频率时，不会更改刷新频率(数据应始终稳定并按照内存芯片数据表的要求进行刷新)。但是使用 400 MHz 的 CPU，您的计算时间会更长，并且会看到更多的刷新；并且 1600 MHz 的计算时间很短，刷新次数也较少。其他影响 - 一些内存请求可能会停止等待刷新结束。

因此，有一些非线性元素具有不同的贡献(对于低频循环，一些是负的，另一些是正的):

• CPU 频率和 DRAM 刷新(绝对时间要求)显然不是线性效应；
• CPU 频率和 Linux 内核周期性任务(它们被安排为每秒运行几次，而不是每十亿个 cpu 周期)
• 真实数据访问DRAM timings ( RAS,CAS ) 以 ns 为单位进行测量(但以内存总线周期设置和报告)，1600 MHz CPU 可能需要 100 个周期才能从内存中获取第一个字节，但 400 MHz CPU 可能需要 60 个周期才能从内存中获取第一个字节.

在您的结果中，最后一个效果看起来是最显着的 - 低 MHz 的低周期，高 MHz 的高周期。使用高频 CPU 可能会停止更多的周期以等待从内存到预充电/激活行/选择列的几十纳秒。在低频率下，相同 ns 的内存延迟将转换为少量的慢速 CPU 周期。