# ハードウェアカウンタ ## 定義 ハードウェアカウンタ(PMC: Performance Monitoring Counter)とは、CPU/GPU が内蔵する計数器で、キャッシュミス・メモリアクセス・CPU サイクル・stall サイクル・ページフォルトなどのマイクロアーキテクチャ事象を低コストで計測する。性能ボトルネックがメモリバウンドか計算バウンドかの判別に使われる。([[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) GPU では内部カウンタが限られ、ホスト側のソフトウェア計装と組み合わせて使う場面が多い。 ### perf(1) での内部イベントディスクリプタと周波数サンプリング(13章) Intel プロセッサの分岐命令は内部イベントディスクリプタ `r00c4`(UMASK 0x0 とイベント選択 0xC4 の組み合わせ)のように、プロセッサマニュアルで公開されるコードで指定できる。`perf(1)` は "branch-instructions" のような可読名を用意するが、新しいプロセッサでは可読名が未対応だったりマッピングにバグが混入する可能性があるため、疑わしい結果は内部イベントディスクリプタでダブルチェックすべきとされる。PMC を対象に `perf record` を使う際は、全イベント記録による法外なオーバーヘッドを避けるためデフォルトで周波数サンプリング(既定 4000Hz)が使われ、この間引きは `-vv` を付けないと出力からは分からない。周波数サンプリングは `record` のみに適用され `stat` は全イベントを数える。サンプリング率・CPU 使用率の上限は `sysctl kernel.perf_event_max_sample_rate` / `kernel.perf_cpu_time_max_percent` で確認できる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.4, §13.4.1) ## 横断的知見 - **PMC の可読名とマッピングのバグは、4章の「スキッド」問題とは別種の精度リスクとして13章が追加した**: 4章は PMC のサンプリング精度問題として「スキッド」(割り込みレイテンシとアウトオブオーダー実行による命令ポインタの不正確さ)を扱い、Intel PEBS・AMD IBS の precise event で解決すると説明する。13章はこれとは別に、可読名から内部イベントディスクリプタへのマッピング自体にバグが混入しうるという、計測前の設定段階のリスクを指摘する。PMC の信頼性は「正しいイベントを選べているか」(13章)と「選んだイベントを正確なタイミングで記録できているか」(4章)という2段階のリスクを持つことになる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.4) - **周波数サンプリングの間引きはデフォルト出力から読み取れない、という実務上の落とし穴がある**: 13章は、PMC イベント(cycles など毎秒数十億回発生しうる)を全件記録すると法外なオーバーヘッドになるため `perf record` がデフォルトで周波数サンプリング(既定4000Hz)を行うと説明するが、この間引きは `-vv` を付けない限り出力に現れない。ProfInfer 等が演算子単位で PMC を差分計測する際の計測条件(サンプリング vs カウンティング)を評価するうえで、この「見えない間引き」はサンプリング精度の解釈に影響しうる注意点である。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.4.1, [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **%CPU と PMC の乖離: IPC が真の仕事量を示す**: [[Brendan Gregg]](2017) は `perf stat` の `cycles` / `instructions` から算出される IPC(Instructions Per Cycle)が、%CPU では見えないメモリバウンドと命令バウンドを区別することを実測で示した。IPC < 1.0 はメモリストールを、IPC ≥ 1.0 は命令律速を示す。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]]) - **クラウド/仮想化環境でのPMCアクセス制限は、CPUとGPUの両方に共通する構造的制約である**: 『詳解 システム・パフォーマンス 第2版』4章は、多くのクラウド環境がゲストのPMCアクセスを無効化しており、Xenの`vpmu`オプションやAWS Nitroのベアメタルインスタンスなど限定的な条件でのみ有効化できると述べる(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]])。これは、GPU側でSM利用率などのマイクロアーキテクチャ情報がハードウェアカウンタに依存し続ける([[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]])という制約と同型であり、CPU・GPUを問わずハードウェアカウンタは仮想化・マルチテナント境界で可視性が失われやすいリソースだといえる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - **オーバーフローサンプリングの精度問題(スキッド)への対処は、CPU側で先行して確立された**: 『詳解 システム・パフォーマンス 第2版』4章は、割り込みレイテンシとアウトオブオーダー実行によって命令ポインタの記録が不正確になる「スキッド」問題を、Intel PEBS・AMD IBSの precise event 機能で解決していると説明する(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]])。ProfInferなどLLM推論プロファイラが演算子単位でPMCを差分計測する際にも同種のタイミング精度が前提になっており、CPU側で確立されたprecise eventの設計思想がGPU/LLM推論プロファイリングのオーバーヘッド設計に暗黙に引き継がれている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **演算子レベルに PMC を結び付けるとボトルネックの種別が判定できる**: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] は `l3d_cache_refill`(メモリ読み出し量)・`mem_access_wr`・`cycles`・`idle-backend-cycles`(stall)などの PMC を演算子の uprobe/uretprobe 間で差分計測し、行列ベクトル乗算で CPU サイクルの 50% 超が stall するメモリ帯域ボトルネックを定量化する。PMC は単独でなく演算子・テンソル次元と対応づけて初めて診断に効く。(Source: [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **MSR(model-specific register)は PMC のプログラミングインターフェイスとして CPU/GPU 双方の低レベル計測を橋渡しする**: 『詳解 システム・パフォーマンス 第2版』6章は、Intel P6 ファミリの PMC が 4 個の MSR(読み出し専用カウンタ 2 個・イベント選択 MSR 2 個)で実現され、イベント選択・UMASK・OS/USR モードビット・CMASK で計測対象を細かく指定できると説明する。Skylake ではハードウェアスレッドごとに固定カウンタ 3 個、コアごとにプログラマブルカウンタ 8 個まで拡張されている。この MSR ベースの設計思想(ハードウェア資源の希少性ゆえにカウンタ数が限られ、計測対象を都度選択・多重化する)は、GPU 側でカウンタ数が限られる制約([[GPU観測性]])と同型であり、ハードウェアカウンタは世代が進んでも「有限の物理レジスタをソフトウェアが選択的に割り当てる」という基本構造を保ち続けている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.4.1.6) - **CPU 側では PMC 由来の高レベルツール(pmcarch・tlbstat)がストールの原因を分類し、GPU/LLM 推論プロファイラの粒度の粗い先行形態になっている**: 書籍のpmcarch(8)は IPC・分岐予測ミス率・LLC ヒット率をシステム全体で毎秒表示し、tlbstat(8)は TLB ウォークによるストール率(KPTI パッチ下で最大 IPC 0.10 まで低下する例)を示す。これはシステム全体〜プロセス単位の粗い粒度であり、ProfInfer 等が演算子単位まで PMC を差分計測する粒度([[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])とは対照的である。CPU 領域の PMC ツールは「まずシステム全体でボトルネック種別(メモリ/命令/TLB)を絞り込み、次に細粒度ツールで箇所特定する」という段階的なワークフローを先に確立しており、GPU/LLM 推論プロファイリングのメソドロジもこの段階構造を踏襲していると読める。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.11, §6.6.12, [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]) - **既存ツールはカウンタ/PC サンプリング中心でホスト視点に偏る**: [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]] は、ROC-profiler・VTune・HPCToolkit 等がカウンタや PC サンプリング中心でホスト視点に寄るのに対し、デバイス上のトレース収集に踏み込む。カウンタによる統計とデバイス計装によるトレースは相補的で、両者の統合が課題として浮かぶ。(Source: [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]]) - **GPU 内部情報はカウンタ依存が残る**: [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]・[[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] はホスト側 eBPF 計装でも SM 利用率などの GPU マイクロアーキテクチャ情報は依然ハードウェアカウンタに依存すると認める。ソフト計装が万能でないことが、PMC の役割を残している([[GPU観測性]])。(Source: [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) - **PAPIより12年早く、event countをcore-baseで厳密定義することでプロセス-コアフィルタリングの曖昧さを排除する設計がLIKWIDにあった**: [[@2010__ICPPW__LIKWID : A Lightweight Performance-Oriented Tool Suite for x86 Multicore Environments]]は、コア上で発生する全イベントを計数しプロセス由来でのフィルタリングを一切行わない「厳密にcore-based」なカウンタ計測を採用し、ユーザーが`likwid-pin`で適切なアフィニティを確保する責任を負うという明快な役割分担を示した。この設計思想は、書籍『詳解 システム・パフォーマンス 第2版』6章が説明するMSRベースの限られたカウンタ資源(P6ファミリで4個、Skylakeでハードウェアスレッドごと固定3個+コアごとプログラマブル8個)を「都度選択・多重化する」という基本構造([[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.4.1.6)と同型であり、限られたハードウェア資源をソフトウェア側がどう単純明快に運用するかという問題に、CPU計測ツールの草創期から一貫した解法(core-base計数+ユーザーによる明示的アフィニティ)が採られてきたことを示す。(Source: [[@2010__ICPPW__LIKWID : A Lightweight Performance-Oriented Tool Suite for x86 Multicore Environments]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.4.1.6) - **LIKWID自身がPAPIとの比較で述べる「インストールの容易さ vs 移植性の広さ」というトレードオフは、ハードウェアカウンタツール一般に繰り返し現れる構造的対立である**: LIKWIDはLinux 2.6の`msr`モジュールのみに依存し外部カーネルパッチ不要という単純さと引き換えにx86系Linuxへの対応に限定される一方、PAPIはBlueGene・Cray XT3/4/5を含む幅広いアーキテクチャ・OSに対応する代わりにプラットフォームごとのカーネルパッチや長大なインストール手順を要する。この対立は、`perf(1)`が可読イベント名とプロセッサ固有の内部イベントディスクリプタ(`r00c4`等)の両方を提供しつつ、新しいプロセッサでは可読名のマッピングにバグが混入しうるという『詳解 システム・パフォーマンス 第2版』13章の指摘([[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.4)とも通じる——「移植性のための抽象化層」を厚くするほど、個々のプラットフォームでの検証コストと設定ミスのリスクが増す、というPMCツール共通のジレンマである。(Source: [[@2010__ICPPW__LIKWID : A Lightweight Performance-Oriented Tool Suite for x86 Multicore Environments]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.4) ## 未解決の問い - LIKWIDのイベントグループ(FLOPS_DP・L2・MEM等の事前設定済み派生メトリクス)とPAPIの高レベルイベントは、抽象化の粒度・対応アーキテクチャの網羅性でどこまで実質的に同等か。両者を横断比較した定量評価は本ソース群には存在しない。 - MSR ベースの PMC プログラミング(イベント選択・UMASK・CMASK)は、GPU/NPU の低レベルカウンタ設定インターフェイスとどこまで構造的に対応するか、それとも別物か。 - ソフトウェア計装(LD/ST フック・uprobe)で、限られた GPU ハードウェアカウンタをどこまで代替できるか。 - GPU/NPU 側 PMC とホスト側 eBPF 計装をどの程度統合できるか(ProfInfer は CPU/OpenCL/NPU を扱うが PMC の統合度は限定的)。 - カウンタ統計(ホスト視点)とデバイス上トレースを結合したとき、どんな相補的洞察が得られるか。 - PAPI(すべてのプロセッサで共通のPMC命名を目指す取り組み)は、GPU/NPUベンダーの独自カウンタ体系にどこまで拡張・統一されうるか(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]])。 - クラウドのマルチテナント制約でPMCアクセスが無効化されている場合、eBPFベースの代替計装(kprobe/uprobe)はどこまでPMC相当の低レベル情報を近似できるか。 - perf(1) の可読名-内部イベントディスクリプタ間マッピングバグは、どの程度の頻度・どのプロセッサ世代で実際に報告されているか。GPU/NPU側の類似カウンタ命名でも同種の問題は起きているか。 ## 関連 - ソース: [[@2017__brendangregg.com__CPU Utilization is Wrong]] / [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] / [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]] / [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] / [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] / [[@2010__ICPPW__LIKWID : A Lightweight Performance-Oriented Tool Suite for x86 Multicore Environments]] - 概念: [[CPU利用率]] / [[Instructions Per Cycle]] / [[GPU観測性]] / [[動的計装]] / [[LLM推論]] / [[テレメトリ]] - エンティティ: [[CUPTI]] / [[NVBit]] / [[hip-analyzer]] / [[Brendan Gregg]] / [[perf]] / [[LIKWID]] / [[PAPI]] - 関連 MOC: [[AI Infra Telemetry - MOC]] ## 出典 - [[@2017__brendangregg.com__CPU Utilization is Wrong]](IPC による CPU-メモリボトルネック診断・%CPU の誤謬) - [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]](演算子別 PMC・stall によるメモリ帯域ボトルネック判定) - [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]](カウンタ中心ツールとデバイス計装の対比) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]](architectural PMC set・PEBS/IBS・カウンティング/オーバーフローサンプリングモード・クラウドでのPMC制限) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]](§6.4.1.6 MSRベースPMC実装・§6.6.9〜§6.6.12 turbostat/showboost/pmcarch/tlbstat) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]](§13.4 内部イベントディスクリプタ・可読名マッピング、§13.4.1 周波数サンプリングのデフォルト挙動とsysctl上限) - [[@2010__ICPPW__LIKWID : A Lightweight Performance-Oriented Tool Suite for x86 Multicore Environments]](§likwid-perfCtr のcore-based計測設計・PAPIとの比較 Table I)