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

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

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

[2015-08-17 10:20:14 警告] 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时间最大百分比):

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

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

0:禁用该机制。无论耗费多少 CPU 时间,都不监控或更正 perf 的采样率。

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

在我看来,这 0 意味着不再检查分析采样率,但频率子系统仍在运行(?)。

有人能解释一下如何完全禁用频率内核分析吗?

编辑:有人建议我尝试构建一个没有 perf 的内核,但我认为这根本不可能。该选项似乎不可切换:

菜单配置

编辑 2:在阅读了更多内容后,我决定可以将其设置kernel.perf_event_max_sample_rate为零。即每秒没有样本。但是,您也不能这样做(来源):

提交 02f98e3e36da106338b7c732fed516420fb20e2a
作者:Knut Petersen
日期:2013 年 9 月 25 日星期三 14:29:37 +0200

perf:强制将 perf_event_max_sample_rate 的下限设为 1

编辑 3:FWIWperf_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% 的任意长度,这些长度是为处理 perf 中断而保留的。

编辑5:

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

帮助

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

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

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

因此我想稍微改变一下我的问题:

我可以使用哪些性能设置来最大限度地减少内核在性能例程中花费的时间?

请记住,总体目标是控制基准测试的随机变化源。如果我无法禁用 perf,我该如何将其对基准测试的影响降至最低?

答案1

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

另外,如果您提到它被重新打开,那么很有可能有多个其他内核设置导致它重新HAVE_PERF_EVENTS打开。

depend on HAVE_PERF_EVENTS在文件中查找Kconfig示例以关闭它们,如INTEL_IOMMU_PERF_EVENTSPERF_EVENTS_AMD_POWER

相关内容