「perf stat」結果のストールサイクルフロントエンドとストールサイクルバックエンドとは何ですか？
Perf stat結果でstalled-cycles-frontendおよびstalled-cycles-backendの意味を知っている人はいますか？インターネットで検索しましたが、答えが見つかりませんでした。ありがとう
$ Sudo perf stat ls
Performance counter stats for 'ls':
0.602144 task-clock # 0.762 CPUs utilized
0 context-switches # 0.000 K/sec
0 CPU-migrations # 0.000 K/sec
236 page-faults # 0.392 M/sec
768956 cycles # 1.277 GHz
962999 stalled-cycles-frontend # 125.23% frontend cycles idle
634360 stalled-cycles-backend # 82.50% backend cycles idle
890060 instructions # 1.16 insns per cycle
# 1.08 stalled cycles per insn
179378 branches # 297.899 M/sec
9362 branch-misses # 5.22% of all branches [48.33%]
0.000790562 seconds time elapsed
理論：
これから始めましょう。現在のCPUはスーパースカラーです。つまり、1サイクル（IPC）で複数の命令を実行できます。最新のIntelアーキテクチャでは、最大4つまでIPC（4 x86命令デコーダー）になります。マクロ/マイクロの融合を議論に入れて、事態を複雑にすることは避けましょう:)。
通常、ワークロードはさまざまなリソースの競合によりIPC = 4に達しません。これは、CPUがサイクルを浪費している（命令の数はソフトウェアによって与えられ、CPUはできるだけ少ないサイクルでそれらを実行する必要があることを意味します）。
CPUが消費する合計サイクルを3つのカテゴリに分けることができます。
- 命令が廃止されるサイクル（有用な作業）
- バックエンドで費やされるサイクル（浪費）
- フロントエンドで費やしたサイクル（浪費）。
IPC of 4）を取得するには、[退役するサイクル]の数をサイクルの総数に近づける必要があります。この段階では、すべてのマイクロ-操作（uOps）はパイプラインから廃止され、その結果をレジスター/キャッシュにコミットします。この段階では、4個以上のuOpsを廃止できます。 4 uOpsを廃止するサイクルでは、全体のIPCが1になります。
バックエンドでストールしたサイクルは、CPUがリソース（通常はメモリ）を待機するか、長いレイテンシの命令（たとえば、transcedentals-sqrt、reciprocals、divisionなど）を完了する必要があるため、無駄です。
フロントエンドで停止したサイクルは、フロントエンドがバックエンドにマイクロ操作を供給しないことを意味するため、無駄です。これは、命令キャッシュにミスがあるか、マイクロオペレーションキャッシュでまだデコードされていない複雑な命令があることを意味します。通常、ジャストインタイムコンパイルされたコードはこの動作を表します。
別のストールの理由は、分岐予測ミスです。それは悪い憶測と呼ばれます。その場合、uOpsは発行されますが、BPが誤って予測したために破棄されます。
プロファイラーでの実装：
BEおよびFEストールサイクルをどのように解釈しますか？
プロファイラーが異なれば、これらのメトリックに対するアプローチも異なります。 vTuneでは、カテゴリ1から3を合計して、100％のサイクルを提供します。 CPUがストールしている（uOpsが廃止されていない）か、有用な作業（uOps）を廃止しているため、それは合理的です。詳細はこちらをご覧ください： https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm
パフォーマンスでは、これは通常発生しません。 フロントエンドで125％のサイクルが停止を見ると、これを実際に解釈する方法がわからないため、これは問題です。 > 1メトリックを4つのデコーダーがあるという事実とリンクできますが、推論を続けると、IPCは一致しません。
さらに良いことに、あなたは問題がどれほど大きいか知らない。何のうち125％？ #cyclesはどういう意味ですか？
個人的には、perfのBEおよびFEが停止したサイクルについて少し疑っていますが、これが修正されることを願っています。
おそらく、ここからコードをデバッグして最終的な答えを得るでしょう： http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin- stat.c
Perfによってエクスポートされた汎用イベントをCPUドキュメントの未加工イベントに変換するには、次を実行します。
more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend
次のようなものが表示されます
event=0x0e,umask=0x01,inv,cmask=0x01
Intel documentation SDM volume 3B （コアi5-2520を持っています）によると：
UOPS_ISSUED.ANY：
- RATがRSに発行したUopの数を各サイクルで増加させます。
- Cmask = 1、Inv = 1、Any = 1に設定して、このコアのストールしたサイクルをカウントします。
私のシステムでevent = 0xb1、umask = 0x01に変換されるstalled-cycles-backendイベントの場合、同じドキュメントに次のように記載されています。
UOPS_DISPATCHED.THREAD：
- 各サイクルでスレッドごとにディスパッチされるuopの総数をカウントします
- Cmask = 1、INV = 1に設定して、ストールサイクルをカウントします。
通常、ストールサイクルは、プロセッサが何か（たとえば、読み込み操作の実行後にメモリが供給される）を待機しているサイクルであり、その他の処理はありません。さらに、CPUのフロントエンド部分は、命令をフェッチしてデコード（UOPに変換）するハードウェアであり、バックエンド部分はUOPを効果的に実行する役割を果たします。
CPUサイクルは、パイプラインが進行中に進まないと「停止」します。
プロセッサパイプラインは多くのステージで構成されています。フロントエンドはこれらのステージのグループで、フェッチフェーズとデコードフェーズを担当し、バックエンドは命令を実行します。フロントエンドとバックエンドの間にはバッファが存在するため、前者が停止した場合、後者にはまだやるべきことがあります。
http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/ から取得
これらのイベントの作成者によると、それらは大まかに定義されており、利用可能なCPUパフォーマンスカウンターによって概算されています。私が知っているように、perfはいくつかのハードウェアイベントに基づいていくつかの合成イベントを計算する式をサポートしていないため、IntelのOptimizationマニュアル（VTuneで実装）のフロントエンド/バックエンドストールバウンドメソッドを使用できません http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B.3.2階層トップダウンパフォーマンス特性化方法論」
%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N );
%Bad_Speculation = 100 * ( (UOPS_ISSUED.ANY – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) / N) ;
%Retiring = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/ N) ;
%BE_Bound = 100 * (1 – (FE_Bound + Retiring + Bad_Speculation) ) ;
N = 4*CPU_CLK_UNHALTED.THREAD" (for SandyBridge)
Andi Kleenのpmu-tools（toplev.py）で行われたように、正しい式はいくつかの外部スクリプトで使用できます。 https://github.com/andikleen/pmu-tools （source ）、 http://halobates.de/blog/p/262 （説明）：
% toplev.py -d -l2 numademo 100M stream
...
perf stat --log-fd 4 -x, -e
{r3079,r19c,r10401c3,r100030d,rc5,r10e,cycles,r400019c,r2c2,instructions}
{r15e,r60006a3,r30001b1,r40004a3,r8a2,r10001b1,cycles}
numademo 100M stream
...
BE Backend Bound: 72.03%
This category reflects slots where no uops are being delivered due to a lack
of required resources for accepting more uops in the Backend of the pipeline.
.....
FE Frontend Bound: 54.07%
This category reflects slots where the Frontend of the processor undersupplies
its Backend.
元のユニバーサルstalled-cyclesの代わりにstalled-cycles-frontendおよびstalled-cycles-backendイベントを導入したコミット。
author Ingo Molnar <mingo@el...> 2011-04-29 11:19:47 (GMT)
committer Ingo Molnar <mingo@el...> 2011-04-29 12:23:58 (GMT)
commit 8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree 9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)
perfイベント：ジェネリックフロントエンドおよびバックエンドストールサイクルイベント定義を追加2つのジェネリックハードウェアイベントを追加：フロントエンドおよびバックエンドストールサイクル。
これらのイベントは、CPUがコードを実行しているが、その機能が完全に利用されていない場合の状態を測定します。このような状況を理解して分析することは、コード最適化ワークフローの重要なサブタスクです。
両方のイベントがパフォーマンスを制限します。ほとんどのフロントエンドストールは、ブランチの予測ミスまたは命令フェッチキャッシュミスによって引き起こされる傾向があり、バックエンドストールは、さまざまなリソース不足または非効率的な命令スケジューリングによって引き起こされる可能性があります。
フロントエンドストールはより重要なものです。命令ストリームが維持されていない場合、コードは高速に実行できません。
バックエンドが過剰に使用されると、フロントエンドのストールが発生する可能性があるため、同様に監視する必要があります。
正確な構成は、プログラムロジックと命令ミックスに大きく依存します。
「ストール」、「フロントエンド」、および「バックエンド」という用語を大まかに使用し、これらの概念に近い特定のCPUから利用可能な最高のイベントを使用しようとします。
Cc：Peter Zijlstra Cc：Arnaldo Carvalho de Melo Cc：Frederic Weisbeckerリンク： http://lkml.kernel.org/n/[email protected] Sign-off-by：インゴ・モルナー
/* Install the stalled-cycles event: UOPS_EXECUTED.CORE_ACTIVE_CYCLES,c=1,i=1 */
- intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES] = 0x1803fb1;
+ intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x1803fb1;
- PERF_COUNT_HW_STALLED_CYCLES = 7,
+ PERF_COUNT_HW_STALLED_CYCLES_FRONTEND = 7,
+ PERF_COUNT_HW_STALLED_CYCLES_BACKEND = 8,