【发布时间】：2019-02-07 21:00:31
【问题描述】：
我在here 上发布了一个类似上下文的问题
在解决了一些问题后，我已经降低了抖动。
我将描述我的场景。
我的内核启动参数如下所示：
nmi_watchdog=0 intel_idle.max_cstate=0 processr.max_cstate=0 nohz_full=7-11 isolcpus=7-11 mce=off rcu_nocbs=7-11 nosoftlockup cpuidle.off=1 powersave=off nonmi_ipi nnwatchdog
我有一个内核模块，它负责以给定的时间间隔发送一些数据包（这里我每 1ms 发送一次）。
- 我有一个固定到 CPU 9 的数据包生成器
- 我有一个固定到 CPU 8 的内核模块（或 Kthread）
- 我已将我的 rx 队列的 IRQ 亲和性设置为 CPU 10
因此，我执行了以下命令来获取性能统计信息
sudo ./perf stat -a -d -I 1000 --cpu=8 taskset -c 9 ./test.sh
下面，我发布了我得到的输出的摘录。通过上面的命令，我试图分析我的 CPU Core 8 的事件。
所以，通过这种方式，这些组件应该不会相互干扰。
5.002780500 1000.296809 cpu-clock (msec) # 1.000 CPUs utilized
5.002780500 0 context-switches # 0.000 K/sec
5.002780500 0 cpu-migrations # 0.000 K/sec
5.002780500 0 page-faults # 0.000 K/sec
5.002780500 88,531 cycles # 0.000 GHz
5.002780500 29,738 instructions # 0.33 insn per cycle
5.002780500 6,639 branches # 0.007 M/sec
5.002780500 118 branch-misses # 1.72% of all branches
5.002780500 7,677 L1-dcache-loads # 0.008 M/sec
5.002780500 318 L1-dcache-load-misses # 4.04% of all L1-dcache hits
5.002780500 196 LLC-loads # 0.196 K/sec
5.002780500 169 LLC-load-misses # 84.08% of all LL-cache hits
Round 0
6.330091222 1327.302728 cpu-clock (msec) # 1.327 CPUs utilized
6.330091222 1 context-switches # 0.001 K/sec
6.330091222 1 cpu-migrations # 0.001 K/sec
6.330091222 0 page-faults # 0.000 K/sec
6.330091222 2,401,268,484 cycles # 2.276 GHz
6.330091222 1,700,438,285 instructions # 4.25 insn per cycle
6.330091222 400,075,413 branches # 379.216 M/sec
6.330091222 9,587 branch-misses # 0.01% of all branches
6.330091222 300,135,708 L1-dcache-loads # 284.487 M/sec
6.330091222 12,520 L1-dcache-load-misses # 0.03% of all L1-dcache hits
6.330091222 6,865 LLC-loads # 0.007 M/sec
6.330091222 5,177 LLC-load-misses # 394.69% of all LL-cache hits
Round 1
7.343309295 1013.219838 cpu-clock (msec) # 1.013 CPUs utilized
7.343309295 2 context-switches # 0.002 K/sec
7.343309295 1 cpu-migrations # 0.001 K/sec
7.343309295 0 page-faults # 0.000 K/sec
7.343309295 2,401,313,050 cycles # 2.289 GHz
7.343309295 1,700,446,830 instructions # 2.48 insn per cycle
7.343309295 400,076,590 branches # 381.375 M/sec
7.343309295 9,722 branch-misses # 0.01% of all branches
7.343309295 300,137,590 L1-dcache-loads # 286.108 M/sec
7.343309295 12,429 L1-dcache-load-misses # 0.01% of all L1-dcache hits
7.343309295 6,787 LLC-loads # 0.006 M/sec
7.343309295 5,167 LLC-load-misses # 246.77% of all LL-cache hits
'Round "x"' 表示我们每毫秒发送 1 个数据包，因此每毫秒发送 1000 个数据包，因此每一轮。
从上面的转储中我无法理解的是LLC-load-misses。或者，准确地说，我无法找到深入挖掘此问题根源的方法。
关于这个问题的任何意见都会非常有帮助。
问候， 库沙尔。
【问题讨论】：
-
您的意思是
LLC-load-misses可以是LL-cache hits的> 100%？我认为最近有一个类似的问题是关于这些事件在不同 CPU 上的确切意义。 -
是的。例如，在第 0 轮结束时，LLC-load-misses 的值为 394.69%。我想更深入地研究造成这种情况的原因，但不确定我应该具体研究哪里。据我了解，这是表示 CPU 无法从缓存中访问事件的指标，对吧？
-
我找不到副本；我想到的实际上是关于混淆 iTLB 事件：how to interpret perf iTLB-loads,iTLB-load-misses。但无论如何，就像Cache misses in an infinite loop with no memory references?，LLC 负载未命中的绝对数量非常低。绝大多数负载在 L1d 中命中，其余一半在 L2 中命中。 L2 中仅缺少随机的局部性差负载，因此 L3 在这里没有帮助。我不知道
246.77%是从哪里计算出来的。 -
这个数字 > 100% 并不一定很奇怪。它是缓存未命中与缓存命中的比率，而不是“命中率”，因此如果您错过了 3 次访问中的 2 次，则您将获得 2 次未命中与 1 次命中的比率，并且因此性能值为 200%。我不确定为什么 perf 选择以这种方式显示它，但是您可以轻松计算其他值，因为您拥有
LLC-load-misses和LLC-loads的原始数据：对于您的 394% 示例，它们是 5,177 / 6,865 = ~75 % 未命中率（25% 命中率）。对于局部性较差的进程来说，这似乎不是一个不合理的值。 -
我的意思是“局部性差”并不一定意味着设计不好或可以改进。如果您的进程做的很少（例如，在这里和这些发送数据包），但它所做的涉及跨内核通信，那么您充其量将一直丢失到 L3，因为这是大多数英特尔 CPU 的共享级别。如果您正在接收数据包，您可能会错过内存，具体取决于网卡的工作方式（即，它是否将数据包转储到内存中，或者它是否具有将数据包置于某个缓存级别的功能）。
标签： linux-kernel kernel-module perf