我正在尝试使用 linux perf 或 python 脚本来分析 L3 缓存带宽。我发现没有可用的命令可以直接测量它。但我知道如何使用以下命令获取 llc 性能计数器。谁能告诉我如何使用性能计数器计算 L3 缓存带宽,或者向我推荐任何可用于测量 L3 缓存带宽的工具?预先感谢您的帮助。
perf stat -e LLC-loads,LLC-load-misses,LLC-stores,LLC-prefetches python hello.py
更新:
perf
已更改,现在您想要perf stat
与-M tma_info_memory_core_l3_cache_access_bw
用于 L3 带宽或-M tma_info_memory_core_l3_cache_fill_bw
用于 DRAM 带宽(L3 填充 = 未命中,我认为?)
它们似乎测量总的读+写带宽,我认为“访问”带宽可能是计算来自核心的读+写加上对 DRAM 的脏写回。使用的测试代码,DRAM中的读写速度存在巨大差异,这正常吗?(在
write
之前使用read
以避免CoW映射到相同的零物理页)与EPP = performance
避免降频。实际上,我注释掉了读取,因此该过程将整个时间都花在写入测试中,从而可以轻松使用perf
:我在写入测试期间测量了22.58 tma_info_memory_core_l3_cache_fill_bw
,而intel_gpu_top
显示了14GB/s读取+14GB/s的峰值写,平均少,包括启动。并且 37.70 tma_info_memory_core_l3_cache_access_bw
在同一测试期间(两个指标组在同一次 perf
运行中都处于活动状态。)
在该测试期间,L3 命中应该可以忽略不计,并且系统的其余部分处于空闲状态,例如根据在 DRAM 控制器上测量的
intel_gpu_top
,读取速度为 200MiB/s,写入速度为 25 MiB/s。
根据我的 Skylake 上的
perf list
,这些报告平均每核 数据 访问或填充带宽(以 GB/s 为单位)。 (所以不计算指令获取,也许只读取?)我不能 100% 确定这些计数器到底测量什么,但是下面我的旧答案中描述的指标组不再存在。我的性能为 6.5那一刻。
perf stat
有一些命名的“指标”,它知道如何从其他事物中计算。根据我系统上的perf list
,这些包括L3_Cache_Access_BW
和L3_Cache_Fill_BW
。
- L3_Cache_Access_BW [L3 缓存的平均每核数据访问带宽 [GB/秒]]
- L3_Cache_Fill_BW [L3 缓存的平均每核心数据填充带宽 [GB/秒]]
这是来自我的 Skylake (i7-6700k) 系统。其他 CPU(尤其是来自其他供应商和架构的)可能对其有不同的支持,或者 IDK 可能根本不支持这些指标。
我尝试了一个简单的埃拉托斯特尼筛(使用布尔数组,而不是位图),来自最近的代码审查问题,因为我有一个可基准测试的版本(带有重复循环)。它测得总带宽为 52 GB/s(我认为是读+写)。 因此,我使用的 n=4000000 问题大小总共消耗 4 MB,这大于 256K L2 大小,但小于 8MiB L3 大小。
$ echo 4000000 |
taskset -c 3 perf stat --all-user -M L3_Cache_Access_BW -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions ./sieve
Performance counter stats for './sieve-buggy':
7,711,201,973 offcore_requests.all_requests # 816.916 M/sec
# 52.27 L3_Cache_Access_BW
9,441,504,472 ns duration_time # 1.000 G/sec
9,439.41 msec task-clock # 1.000 CPUs utilized
0 context-switches # 0.000 /sec
0 cpu-migrations # 0.000 /sec
1,020 page-faults # 108.058 /sec
38,736,147,765 cycles # 4.104 GHz
53,699,139,784 instructions # 1.39 insn per cycle
9.441504472 seconds time elapsed
9.432262000 seconds user
0.000000000 seconds sys
或者只有
-M L3_Cache_Access_BW
而没有 -e
事件,它只显示 offcore_requests.all_requests # 54.52 L3_Cache_Access_BW
和 duration_time
。所以它会覆盖默认值并且不计算cycles,instructions
等等。
我认为这只是计算该核心的所有非核心请求,假设(正确地)每个请求都涉及 64 字节传输。 L3 缓存中是否命中或未命中都会被计数。与 DRAM 控制器上的非核心瓶颈相比,获得大部分 L3 命中显然可以实现更高的带宽。