ユーザー/カーネル空間でプロセスが費やしたCPU時間を理解する

ユーザー/カーネル空間でプロセスが費やしたCPU時間を理解する

通常、以下を報告するアプリケーションがあります(timeコマンドレポート)。

real 1.59
user 1.42
sys 4.73

ただし、共有ライブラリをロードして実行すると、時間がかなり長くなります(timeコマンドレポート)。

real 28.51
user 106.22
sys 5.23

私の共有ライブラリの操作はわずかなスピードアップを期待していましたが(CentOSとUbuntuでは2〜4倍が報告されると予想されています)、Fedora 24で上記の時間が長すぎます。

レポートを使用しようとしていますperf

     255352.948615      task-clock:u (msec)       #    3.895 CPUs utilized
                 0      context-switches:u        #    0.000 K/sec
                 0      cpu-migrations:u          #    0.000 K/sec
            18,127      page-faults:u             #    0.071 K/sec
   664,852,184,198      cycles:u                  #    2.604 GHz                      (50.03%)
    19,323,811,463      stalled-cycles-frontend:u #    2.91% frontend cycles idle     (50.02%)
   578,178,881,331      stalled-cycles-backend:u  #   86.96% backend cycles idle      (50.02%)
   110,595,196,687      instructions:u            #    0.17  insn per cycle
                                                  #    5.23  stalled cycles per insn  (50.00%)
    28,361,633,658      branches:u                #  111.068 M/sec                    (50.01%)
       777,249,031      branch-misses:u           #    2.74% of all branches          (50.01%)

      65.564158710 seconds time elapsed

これは、CPUが長時間アイドル状態であることを示すようです。しかし、コードでこれが起こる場所を見つけようとしています(私のアプリケーションの完全なソースコードと関連する共有ライブラリにアクセスできます)。また、perf report関数/システムコールに費やされた時間の割合を報告することも見ました。しかし、私はその理由を理解するために、より細かいレベル、つまりこれらの関数にどのような行があるかに興味があります。

私のアプリケーション/共有ライブラリについて多くの情報を提供していないので、具体的なアドバイスを提供するのは簡単ではないことは幸いです。私は、CPUがほとんどの時間を費やしている場所(またはアイドル状態)をコードで特定するために提案/ツール/アイデアを探しています。

glibc 2.23がインストールされているFedora 24 Linux / x86_64です(私のアプリケーションと共有ライブラリはgcc 6.1.1とglibc 2.23にコンパイルされました)。

答え1

これは、CPUが長時間アイドル状態であることを示すようです。

はい。 87%の時間です。しかし、これはプロセッサが他のタスクやプロセスを処理しないという意味ではありません。

   664,852,184,198      cycles:u                  #    2.604 GHz                      (50.03%)
    19,323,811,463      stalled-cycles-frontend:u #    2.91% frontend cycles idle     (50.02%)
   578,178,881,331      stalled-cycles-backend:u  #   86.96% backend cycles idle      (50.02%)
   110,595,196,687      instructions:u            #    0.17  insn per cycle

CPUとメモリアクセスをよりよく活用するようにプログラムを最適化することは複雑な作業であり、コードがなければより詳細に答えることは不可能です。

関連情報