如何在 Linux 内核中禁用 perf 子系统?

Edd*_*ett 16 linux dmesg kernel benchmark

我正在运行一些基准测试。我的基准运行程序监视实验之间的 dmesg 缓冲区,寻找可能影响性能的任何内容。今天它抛出了这个:

[2015-08-17 10:20:14 WARNING] dmesg 好像变了!差异如下:
--- 2015-08-17 09:55:00
+++ 2015-08-17 10:20:14
@@ -825,3 +825,4 @@
 [3.802206][drm]启用RC6状态:RC6开启,RC6p关闭,RC6pp关闭
 [7.900533]r8169 0000:06:00.0 eth0:链接
 [7.900541]IPv6:ADDRCONF(NETDEV_CHANGE):eth0:链接准备好
+[236832.221937] perf 中断时间太长 (2504 > 2500),将 kernel.perf_event_max_sample_rate 降低到 50000

经过一番搜索,我现在知道这与 linux 内核中名为“perf”的分析子系统有关。我认为我们不需要这个,所以我想完全禁用它。

再次搜索,我发现 sysctlperf_cpu_time_max_percent可以提供帮助。这里有人建议通过将其设置为 0 来禁用。在这里阅读更多内容:

perf_cpu_time_max_percent:

向内核提示应该允许使用多少 CPU 时间来处理性能采样事件。如果 perf 子系统被告知其样本超过此限制,它将降低其采样频率以尝试减少其 CPU 使用率。

一些性能采样发生在 NMI 中。如果这些样本意外地花费了太长时间来执行,则 NMI 可能会彼此堆叠在一起,以至于不允许执行任何其他操作。

0:禁用该机制。无论 CPU 时间有多长,都不要监视或更正 perf 的采样率。

1-100:尝试将 perf 的采样率限制到 CPU 的这个百分比。注意:内核计算每个样本事件的“预期”长度。这里的 100 表示预期长度的 100%。即使将其设置为 100,如果超过此长度,您仍可能会看到样本节流。如果您真的不关心消耗了多少 CPU,则设置为 0。

这听起来像 0 意味着不再检查分析采样率,但频率子系统保持运行(?)。

任何人都可以阐明如何使用 freq 完全禁用内核分析吗?

编辑:有人建议我尝试在没有 perf 的情况下构建内核,但我认为这甚至不可能。该选项似乎不可切换:

菜单配置

EDIT2:经过更多阅读,我决定我可以设置kernel.perf_event_max_sample_rate为零。即每秒没有样本。但是,您也不能这样做(来源):

提交 02f98e3e36da106338b7c732fed516420fb20e2a
添加一名作者 
日期:2013 年 9 月 25 日星期三 14:29:37 +0200

perf:强制 1 作为 perf_event_max_sample_rate 的下限

编辑 3:FWIW,perf_cpu_time_max_percent设置为 25,这意味着内核花费了超过 25% 的时间来采样硬件寄存器。这对于基准测试机来说是不可接受的。

我现在确信设置perf_cpu_time_max_percent为零只会使情况恶化,因为内核将继续使用超过 25% 的时间来读取硬件寄存器。该错误会触发以调整采样率,从而试图确保内核满足其在性能中使用 <25% 的时间的配额。恕我直言,25% 仍然太高了。

如果我真的不能禁用 perf,最好的折衷办法可能是设置perf_event_max_sample_rate为 1。

EDIT4: 一位朋友建议我可能误解了 的意思perf_cpu_time_max_percent,所以上面的陈述可能是不正确的。值 25 表示内核使用了超过 25% 的某个任意长度,它为服务性能中断保留。

编辑5:

正如评论中所指出的,-*-反对 perf 选项表明该功能是由另一个启用的功能强制启用的。如果我查看help,它会说明这些功能是:

帮助

我不认为我能在这里赢。布尔公式selected by

如果您的目标是 X86,或者...

我刚刚检查了针对 X86_64 确实启用了CONFIG_X86. 因此,似乎只要您以 X86 或 X86_64 为目标,您就会获得性能。

所以我想稍微改变一下我的问题:

我可以使用哪些 perf 设置来最小化内核在 perf 例程中花费的时间?

请记住,总体目标是控制基准测试的随机变化源。如果我不能禁用 perf,我怎样才能最大限度地减少它对基准的影响?

Joh*_*ene 2

禁用HAVE_PERF_EVENTS内核选项并重新编译 Linux 内核。

另外,如果您提到它已翻转回打开状态,则。很有可能有不止一种其他内核设置导致HAVE_PERF_EVENTS打开。

depend on HAVE_PERF_EVENTS在文件中查找Kconfig也可以关闭的示例,例如INTEL_IOMMU_PERF_EVENTS, PERF_EVENTS_AMD_POWER