perfとハードウェアパフォーマンスカウンタ

「推測でなく実測する」ためのハードウェア

性能チューニングで最も危険なのは、ボトルネックを勘で当てに行くことです。「ここが遅いはず」という思い込みは外れることが多く、実際のCPUは キャッシュ階層 や分岐予測、パイプラインといった見えにくい要因に律速されています。これらは普通のプログラムからは観測できません。

そこで現代のCPUは、自分自身の挙動を数える専用ハードウェアを内蔵しています。それが PMU（Performance Monitoring Unit） であり、Linux でそれを使う標準ツールが perf です。核心は「ソフトウェアの計測コードを挟まずに、ハードが直接イベントを数える」点にあります。命令を1つ実行するたびにカウンタを増やすコードを書けば、その計測コード自体が支配的なオーバーヘッドになります。PMU はそれをゲートレベルで行うため、本来の実行をほぼ妨げません。

PMUとパフォーマンスカウンタの構造

PMU の実体は、CPU コアごとに置かれた少数の PMC（Performance Monitoring Counter） レジスタ群です。各カウンタには「何を数えるか」を指定する イベントセレクタ（モデル固有レジスタ、MSR）が紐付き、そこにイベント番号・ユニットマスク・特権レベル（ユーザー/カーネルどちらで数えるか）などを設定します。設定後はハードがそのイベントの発生回数を黙々と加算します。

イベントは大きく2種類あります。

ここで効いてくる物理的な制約が カウンタの本数 です。汎用カウンタは1コアあたり数本（世代によりおおむね 4〜8 本）しかありません。固定機能カウンタはサイクル数や命令数といった頻出イベント専用に用意され、汎用カウンタを消費しません。なぜこの区別が重要かというと、IPC（命令数 ÷ サイクル数）のような基礎指標を、限られた汎用カウンタを使わずに常時取れるからです。

カウントとサンプリング：2つの計測モード

PMU の使い方には原理的に異なる2つのモードがあります。この違いを理解することが perf 習得の山です。

カウントモード（counting） は、ある区間でイベントが合計何回起きたかを集計します。perf stat がこれにあたります。区間の開始時にカウンタをゼロにし、終了時に値を読むだけなので、オーバーヘッドが極めて小さく、IPC やミス率といった全体傾向を測るのに向きます。ただし「どこで」起きたかは分かりません。

perf stat -e cycles,instructions,cache-misses,branch-misses ./app

         12,345,678,901      cycles
          9,876,543,210      instructions   #  0.80  insn per cycle
            123,456,789      cache-misses
             23,456,789      branch-misses   #  3.21% of all branches

サンプリングモード（sampling） は、イベントを N 回数えるごとに1回だけ割り込みを上げ、その瞬間のプログラム状態（命令ポインタ、レジスタ、コールスタック）を記録します。perf record がこれです。これにより「キャッシュミスがどの関数・どの命令に集中しているか」という空間的な分布が得られます。

サンプリングの周期は2通りで指定します。period（イベント N 回ごと）を固定する方式と、freq（1秒あたりの目標サンプル数）を指定し、カーネルが周期を自動調整する方式です。後者は負荷の異なる区間でもサンプル数を一定に保てます。

PEBS：割り込みスキューを潰す仕組み

サンプリングには厄介な根本問題があります。**スキュー（skew）**です。カウンタがオーバーフローしてから、CPU が割り込みを受け付けて状態を記録するまでには遅延があり、その間にパイプラインは次々と命令を実行します。結果、記録される命令ポインタは「実際にイベントを起こした命令」より数命令〜数十命令ずれます。これを skid と呼びます。アウトオブオーダ実行や深いパイプラインほど skid は大きくなります。

これを解決するのが PEBS（Precise Event-Based Sampling） です（AMD では IBS が近い役割を担います）。発想はこうです。割り込みでソフトに状態採取を任せるのではなく、ハードウェアがイベント発生時点の正確なレジスタ状態を、あらかじめ確保したメモリ領域（PEBSバッファ）へ直接書き込む。CPU はバッファが閾値に達したときだけ割り込みを上げ、まとめて回収します。

[従来サンプリング]  オーバーフロー → 割り込み → ハンドラが状態採取
                                       ↑ この間に命令が進む = skid

[PEBS]  イベント発生 → ハードが正確な状態をバッファへ直書き
                       バッファ満杯時のみ割り込み（回収専用）

PEBS の利点は2つです。第一に、記録地点がイベント発生命令に正確に対応する（precise）こと。perf の :p / :pp / :ppp という精度サフィックスはこの PEBS の利用度を表します。第二に、割り込み頻度が下がり、オーバーヘッドが減ること。さらに PEBS レコードにはデータアドレスやレイテンシなどの付加情報を載せられ、perf mem や perf c2c（キャッシュライン競合の検出）といった高度な解析を支えます。

perf_eventサブシステム：ハードを抽象化する

ユーザーが直接 MSR を叩くわけにはいきません。MSR 操作は特権命令であり、コア間の整合や カーネルとユーザーの境界 の管理が必要だからです。この橋渡しをするのが Linux の perf_event サブシステム で、入口は perf_event_open(2) という システムコール 1本です。

このサブシステムが提供する重要な抽象は次のとおりです。

• イベントの仮想化：プロセスやスレッドに紐付いた「仮想カウンタ」を作る。コンテキストスイッチ のたびにカーネルがカウンタ値を退避・復元するため、対象タスクが他コアへ移っても、そのタスクだけの値を追える。
• 多重化（multiplexing）とスケーリング：要求したイベント数が物理カウンタ本数を超えると、カーネルは時分割でイベントを入れ替えて測る。ただし各イベントは一部の時間しか動かないため、enabled 時間と running 時間の比で値を**外挿（スケーリング）**する。
• リングバッファ：サンプルや PEBS レコードを、mmap された共有リングバッファ経由でユーザー空間へ低コストで渡す。

観測がもたらすオーバーヘッド

「PMU は本来の実行を妨げない」と述べましたが、これは厳密には正しくありません。観測は必ず対象を乱す（観測者効果）。原理から見て、オーバーヘッドの源は次の3つです。

1. 割り込みコスト：サンプリングでは周期ごとに割り込みが入り、ハンドラがスタックを巻き戻し（コールグラフ採取）、レコードをバッファへ書く。周期 N を小さくするほど精度は上がるが割り込み頻度も上がり、計測対象を遅くする。
2. キャッシュ・TLB汚染：ハンドラやコールスタック走査が、対象プログラムのデータを キャッシュ から追い出す。皮肉にも、キャッシュミスを測る行為自体がキャッシュミスを増やす。
3. コンテキストスイッチ時の退避コスト：仮想カウンタは切り替えのたびに save/restore が走る。多数のイベントを張るほどこの定数コストが積み上がる。

カウントモードのオーバーヘッドは無視できるほど小さい一方、高頻度サンプリングや深いコールグラフ採取は数%以上の歪みを生み得ます。測りたい現象を、測る行為が壊さないかを常に意識する必要があります。

まとめ