私は以下のスイッチと私のC++コードをコンパイル

Question

を実行しているC++アプリケーションでkernel.kallsymsの役割：

g++ -O0 -g -rdynamic -DNDEBUG -DARMA_NO_DEBUG -std=c++11 -pthread 

リンカスイッチは、次のとおりです。

-lboost_system -lboost_thread -lboost_chrono -larmadillo -pthread 

しかし、私は、私にはスレッドを使用しません応用。私はまた、delay関数の使用を避けます。

次にコードを実行し、perfツールでテストします。

sudo perf record ./bin/my_application 
sudo perf report -f 

結果は私には奇妙です：

Overhead Command   Shared Object  Symbol 
50.92% myApplication [kernel.kallsyms] [k] native_sched_clock 
24.73% myApplication [kernel.kallsyms] [k] pick_next_entity 
17.46% myApplication [kernel.kallsyms] [k] prepend_name 
    2.57% myApplication myApplication  [.] arma::arrayops::copy_small<double> 
    1.11% myApplication myApplication  [.] arma::Mat<double>::Mat 
    1.11% myApplication myApplication  [.] myClass::myMethod 
    1.11% myApplication libblas.so.3  [.] dgemv_ 
    0.97% myApplication myApplication  [.] arma::Mat<double>::init_cold 

kernel.kallsyms機能が実行時間を支配しているのはなぜ？

私のアプリケーションではそれぞれnative_sched_clock,pick_next_entity,prepend_nameとなりますか？

Answer 1

あなたのアプリケーションは速すぎて短く、デフォルトの頻度であるperf recordでプロファイルされません。 [k]と[kernel.kallsyms]の行はすべて、カーネルのバイナリのロードやスレッド/プロセスのスケジューリング（ ``）などのサービスジョブを実行しています。ほとんどの仮想化された環境でゲストカーネルのハードウェアパフォーマンスカウンタにアクセスすることができないため、xen、kvm、....のような仮想化されたプラットフォームでperfを使用すると、問題が発生する可能性があります（AWSはサイクルの基本サブセットと、インスタンス）; perfはソフトウェアタイマ割り込みを使用します。

測定したいコードの周りにループを追加してください（100回または1000回繰り返します）。または処理するデータのサイズを増やしてください。あなたのプログラムは、少なくとも数秒間実行する必要があります。

perf stat ./programを実行して、プログラムのタイミング値と基本的なハードウェアパフォーマンスのカウント（カウンタがサポートされている場合）を取得し、結果を通知することもできます。