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に下げました

いくつかの検索の後、これは「perf」と呼ばれるLinuxカーネルのプロファイリングサブシステムに関連していることがわかりました。これが必要だとは思わないので、完全に無効にしたいと思います。

もう一度検索すると、sysctl perf_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サブシステムは実行されたままです（？）。

誰でもfreqでカーネルプロファイリングを完全に無効にする方法に光を当てることができますか？

編集：誰かがperfなしでカーネルを構築しようと提案したが、これは可能だとさえ思わない。オプションは切り替え可能ではないようです：

EDIT2：さらに読んだ後、kernel.perf_event_max_sample_rateゼロに設定できる可能性があると判断しました。つまり、1秒あたりのサンプルはありません。ただし、これもできません（source）：

コミット02f98e3e36da106338b7c732fed516420fb20e2a
著者：クヌート・ピーターセン 
日付：2013年9月25日水曜日14:29:37 2013 +0200

perf：perf_event_max_sample_rateの下限として1を強制します

編集3：FWIW perf_cpu_time_max_percentは25に設定されています。つまり、カーネルはハードウェアレジスタのサンプリングに時間の25％以上を費やしていました。これは、ベンチマークマシンでは受け入れられません。

perf_cpu_time_max_percentカーネルはハードウェアレジスタの読み取り時間の25％以上を使用し続けるため、ゼロに設定しても状況が悪化するだけであると確信しています。エラーが発生してサンプルレートが調整されるため、カーネルがperfでの時間の<25％を使用するクォータを確実に満たそうとします。私見ではまだ25％が高すぎます。

本当にperfを無効にできない場合、おそらく最良の妥協点はperf_event_max_sample_rate1 に設定することです。

EDIT4：友人は、私がの意味を誤って解釈した可能性があることを示唆したperf_cpu_time_max_percentため、上記の記述は間違っている可能性があります。値25は、カーネルがperf割り込みの処理に予約していた任意の長さの25％以上を使用したことを示します。

EDIT5：

コメントで指摘されているように、-*-perfオプションに対する反対は、機能が別の有効な機能によって強制されることを示唆しています。を見るとhelp、これらの機能は次のとおりです。

ここで勝てるとは思わない。ブール式selected byは言う

X86をターゲットにしている場合、または...

X86_64をターゲットにすることで実際に有効になることを確認しましたCONFIG_X86。したがって、X86またはX86_64をターゲットにするとすぐにパフォーマンスが向上するようです。

だから私は私の質問を少し変更したいと思います：

perfルーチンでカーネルが費やす時間を最小限に抑えるために、どのperf設定を使用できますか？

全体的な目的は、ベンチマークのためにランダムな変動の原因を制御することです。パフォーマンスを無効にできない場合、ベンチマークへの影響を最小限に抑えるにはどうすればよいですか？

[HAVE_PERF_EVENTS]カーネルオプションを無効にして、Linuxカーネルを再コンパイルします。