perf statが "stalled-cycles-backend"を<サポートされていない>と表示するのはなぜですか？
ランニング perf stat lsはこれを示しています：
Performance counter stats for 'ls':
1.388670 task-clock # 0.067 CPUs utilized
2 context-switches # 0.001 M/sec
0 cpu-migrations # 0.000 K/sec
266 page-faults # 0.192 M/sec
3515391 cycles # 2.531 GHz
2096636 stalled-cycles-frontend # 59.64% frontend cycles idle
<not supported> stalled-cycles-backend
2927468 instructions # 0.83 insns per cycle
# 0.72 stalled cycles per insn
615636 branches # 443.328 M/sec
22172 branch-misses # 3.60% of all branches
0.020657192 seconds time elapsed
停止したサイクルのバックエンドが「サポートされていない」と表示されるのはなぜですか？この値を確認するには、どのような種類のCPU、ハードウェア、カーネル、ユーザースペースソフトウェアが必要ですか？
現在、異なるIntel Core i5およびi7システム（Ivy Bridgeタイプ）で、一致する「perf」バージョンを使用して、x86_64用のLinux 3.12を備えたRHELでこれを試しました。それらのどれもストールサイクルバックエンドをサポートしていません。
さらに詳しい情報：
$ perf list | grep stalled
stalled-cycles-frontend OR idle-cycles-frontend [Hardware event]
stalled-cycles-frontend OR cpu/stalled-cycles-frontend/ [Kernel PMU event]
$ ls /sys/devices/cpu/events/
branch-instructions bus-cycles cache-references instructions mem-stores
branch-misses cache-misses cpu-cycles mem-loads stalled-cycles-frontend
$ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend
event=0x0e,umask=0x01,inv,cmask=0x01
編集： AMD Phenom II X6 1045T CPU、Linux 3.2（32ビット）を搭載したUbuntu 12.04でこれを試したところ、stalled-cycles-frontendとstalled-cycles-backendの両方の値が表示されます。
perfは、Ivy Bridgeがサポートするすべてのパフォーマンス監視イベントを理解するように更新されていないようです。幸いにも、面倒ではありますが、パフォーマンス監視イベントの完全なリストにアクセスできる汎用的なインターフェイスがあります。簡単に見たときにリストに_stalled-cycles-backend_が表示されませんでしたが、見逃しているか、バックエンドをストールさせる可能性のあるすべてのイベントによって分類されていない可能性があります。
で始まる
_perf list --help
_...以下を示します[〜＃〜] note [〜＃〜]
_ 1. Intel(R) 64 and IA-32 Architectures Software Developer's Manual
Volume 3B: System Programming Guide
http://www.intel.com/Assets/PDF/manual/253669.pdf
_...最終的にそのURLで武装
_http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf
_...セクション19.3が必要
19.3第3世代INTEL®CORE™プロセッサーのパフォーマンス監視イベント第3世代Intel®Core™プロセッサーおよびIntel XeonプロセッサーE3-1200 v2製品ファミリーは、Intelマイクロアーキテクチャーのコード名Ivy Bridgeに基づいています。これらは、表19-1にリストされているアーキテクチャパフォーマンスモニタリングイベントをサポートします。プロセッサコアの非アーキテクチャパフォーマンスモニタリングイベントを表19-5に示します。表19-5のイベントは、CPUIDシグネチャがDisplayFamily_DisplayModelエンコーディングで、値が06_3AHのプロセッサに適用されます。
...architecturalイベントの場合は表19-1が必要
19.1アーキテクチャパフォーマンス監視イベントアーキテクチャパフォーマンスイベントは、Intel Core SoloおよびIntel Core Duoプロセッサで導入されています。これらは、Intel Coreマイクロアーキテクチャに基づくプロセッサでもサポートされています。表19-1に、汎用パフォーマンスカウンターと関連するイベント選択レジスタを使用して構成できる、事前定義されたアーキテクチャパフォーマンスイベントを示します。
**表19-1。建築パフォーマンスイベント
...ここでトリッキーな部分が来ます。_UMask Value_を上位2桁の16進数として受け取り、_Event Num_は_perf stat_。
_perf stat --help
__-e, --event= Select the PMU event. Selection can be a symbolic event name (use perf list to list all events) or a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a hexadecimal event descriptor._
... NNNと表示されていますが、NNNNと指定できます。これが機能することを確認し、_perf stat_にキャッシュミスがないかどうかを、シンボリックイベント名と表19-1の16進数の両方で確認します。簡単にするためにdateコマンドを呼び出します。
_$ perf stat -e r412e -e cache-misses date
Fri Mar 28 09:28:52 CDT 2014
Performance counter stats for 'date':
2292 r412e
2292 cache-misses
0.003322663 seconds time elapsed
$
_あなたが見ることができるように両方が同じ数を報告したので、これまでのところ良い。次に、非アーキテクチャハードウェアレジスタについて表19-5に進みます。ここにはリストが多すぎますが、いくつかリストします。
perf（またはそのカーネル部分）は、CPUをサポートするように更新されていないため、perfは一般的なイベント名「stalled-cycles-backend」を実際のHWイベントにマップできません。
そのような場合、イベント名を見つけるのは簡単です。例えばIntel CPU向け-Intelの最適化マニュアルから http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf （イベントをグループ化タイプ別、およびそれらを使用してさまざまな部品を測定する方法を説明します）。 AMDに類似したドキュメントはありません。
生のイベントIDに手動で変換せずにperfでイベント名を使用するには（amdnが彼の answer で言うように）、perfmon2からの変換スクリプトshowevtinfoおよびcheck_eventsを使用できます（- libpfm4 ;サンプルフォルダー）、Bojan Nikolicによる記事「CPUパフォーマンスイベントの全範囲を監視する方法」 http： //www.bnikolic.co.uk/blog/hpc-prof-events.html 。 perfmon2はAMDおよびIntel CPUを理解しており、C/C++で記述されています
Intel CPUの場合、最も簡単な方法は、Intelのオープンソースからのocperfに対してperf wrapperを使用することですpython githubでホストされているAndi Kleen "pmu-tools"によるプロジェクト https://github.com/andikleen/pmu-tools で、ここでMLで紹介されています https：/ /lwn.net/Articles/556983/ およびAndiのブログ http://halobates.de/blog/p/245
ocperfは、インテルの最適化マニュアルのすべてのIntelイベント名を理解します。
ocperfは、古いLinuxカーネルでのすべてのHWイベントもサポートします。 https://download.01.org/perfmon/ にすべてのHWイベントとそのコードを含むtsvまたはjson形式の独自のデータベースがあります（pmu-toolsには自動ダウンローダーがあります）。データベースはインテルの雇用主によって常に更新されています。データベースのフォーマットはreadmeに文書化されています： https://download.01.org/perfmon/readme.txt
Sandy Bridge/Ivy BridgeまたはHaswell、およびカーネル3.10以降の場合、toplev.py scriptfrom "pmu-tools" to toパフォーマンスを調査します。これは、作者のAndi Kleenによる説明です http://halobates.de/blog/p/262 "pmu-tools、パートII：toplev "Ahmad Yasinの" TopDown "メソッドに基づいています "マイクロアーキテクチャーの問題のトップダウン特性評価を使用してアプリケーションを調整する方法 および " トップダウン分析。パフォーマンスカウンターで失われることはありません "
見つかったばかり Re：perf、x86：残りのhaswell PMU機能の一部を追加 ：
> AFAICS backend stall cycles are documented to work on Ivy Bridge.
I'm not aware of any documentation that presents these events
as accurate frontend/backend stalls without using the full
TopDown methology (Optimization manual B.3.2)
したがって、IIUC stalled-cycles-backendカウンターはIvy Bridgeでの信頼性が高すぎるため、カーネル開発者がそれらをサポートしないことに決めました。
Linuxの perf_event_intel.c は、Nehalem、Xeon E7、SandyBridgeではPERF_COUNT_HW_STALLED_CYCLES_BACKENDをサポートしていますが、IvyBridgeではサポートしていません。ただし、PERF_COUNT_HW_STALLED_CYCLES_FRONTENDはIvyBridgeでサポートされています。
したがって、現在のCPUでこのカウンタを取得する方法はないと思います。CPUを切り替えるか、メールに記載されている完全なトップダウンの方法論を使用します（および here および ここ ）