Perf统计周期数和频率缩放

Question

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

希望在高或低频率运行时周期数应该是相同的，但我可以看到一个小的变化，例如在400 the、1000 the和1600 the运行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，具有很好的车顶模型标度运算强度和较低的内存读写量，但仍然存在内存访问，它们的延迟与CPU频率不成线性关系。)

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

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

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

当您更改CPU时钟频率时，您可能(或不可能)也会影响内存控制器/内存总线频率(这是特定于您的SoC和引导配置的)。DRAM内存(可能是“Exynos5422”中的LPDDR3 )有许多按内存总线频率计算的时间，但实际上它们来自实际内存数据库频率和延迟。

在绝对(ns)时间中，大多数时间都是相同的(或关闭)，但是有一个会影响您的代码周期：内存刷新定时 - DRAM内存只保留很短的时间(数据单元的电荷泄漏)，类似于每32微秒( ms )或64 ms(这随着高温而变化，通常有两个值--低温和较高的温度)。使用完整的数据库刷新命令，它将在一段时间内无法访问，比如2%或5% (我没有确切的值)。

更改CPU频率时，不更改刷新频率(数据应始终保持稳定，并按照内存芯片数据表的要求进行刷新)。但使用400 MHz CPU，您的计算将更长，将看到更多刷新；使用1600 MHz计算是短的，将看到较少的刷新。其他效果--一些内存请求可能会被延迟，等待刷新结束。

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

• CPU频率和DRAM刷新(绝对时间要求)显然不是线性效应；
• CPU频率和Linux内核周期任务(它们计划每秒运行几次，而不是每10亿个cpu周期)
• 实际数据访问德拉姆时间 (RAS，CAS)是以ns (但在内存总线周期中设置和报告)来测量的，MHz CPU可能有100个周期从内存中获取第一个字节，而MHz CPU可能有60个周期从内存中获取第一个字节。

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