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時間に関係なく、パフォーマンスのサンプリングレートを監視または修正しないでください。
1-100：perfのサンプルレートをこのCPUの割合に絞ろうとします。注：カーネルは、各サンプルイベントの「予想される」長さを計算します。ここでの100は、予想される長さの100％を意味します。これが100に設定されていても、この長さを超えると、サンプルのスロットルが表示される場合があります。 CPUの消費量を本当に気にしない場合は、0に設定します。
これは0のように聞こえますが、これはプロファイリングのサンプルレートがチェックされなくなったことを意味しますが、freqサブシステムは実行中のままです（？）。
誰もがfreqでカーネルプロファイリングを完全に無効にする方法に光を当てることができますか？
編集：誰かがperfなしでカーネルを構築しようと提案しましたが、これは可能でさえないと思いますオプションは切り替えできないようです：
EDIT2：さらに読んだ後、kernel.perf_event_max_sample_rateをゼロに設定できる可能性があると判断しました。つまり1秒あたりのサンプルはありません。ただし、これを行うこともできません（ source ）：
commit 02f98e3e36da106338b7c732fed516420fb20e2a 作成者：Knut Petersen 日付：Wed Sep 25 14:29:37 2013 +0200 perf：1以下を強制perf_event_max_sample_rate の制限
編集3：FWIW、perf_cpu_time_max_percentは25に設定されています。これは、カーネルがハードウェアレジスタのサンプリングに25％以上費やしていたことを意味します。これは、ベンチマークマシンでは受け入れられません。
カーネルが25％を超えて使用することを継続するため、perf_cpu_time_max_percentをゼロに設定しても状況が悪化するだけであると確信しています。ハードウェアレジスタを読み取る時間。エラーは、サンプルレートを調整するために発生します。したがって、カーネルが、perfでの時間の25％未満を使用するというクォータを確実に満たそうとします。 25％はまだ高すぎます。
私が本当にパフォーマンスを無効にできない場合、おそらく最善の妥協案はperf_event_max_sample_rateを1に設定することです。
EDIT4：友人が私がperf_cpu_time_max_percentの意味を誤って解釈している可能性があるため、上記の記述が正しくない可能性があることを提案しました。値25は、カーネルがパフォーマンス割り込みのサービス用に予約した任意の長さの25％以上を使用したことを示します。
EDIT5：
コメントで指摘されているように、perfオプションに対する-*-は、機能が別の有効な機能によって強制されていることを示唆しています。 helpを見ると、これらの機能は次のとおりです。
ここでは勝てないと思います。ブール式selected byは言う
X86をターゲットにしている場合、または...
X86_64をターゲットにすると実際にCONFIG_X86が有効になることを確認しました。したがって、X86またはX86_64をターゲットにするとすぐに、パフォーマンスが向上するようです。
だから私は私の質問を少し変更したいと思います：
カーネルがパフォーマンスルーチンに費やす時間を最小限に抑えるために、どのパフォーマンス設定を使用できますか？
全体的な目的は、ベンチマークのランダムな変動の発生源を制御することであることを覚えておいてください。パフォーマンスを無効にできない場合、ベンチマークへの影響を最小限に抑えるにはどうすればよいですか？
[HAVE_PERF_EVENTS]カーネルオプションを無効にし、Linuxカーネルを再コンパイルします。