私は走った
perf stat -e itlb_misses.miss_causes_a_walk,itlb_misses.walk_completed,itlb_misses.walk_pending grep Hecuba /storage/nvme6/complete_shakespeare_4096_times
そして得た
Performance counter stats for 'grep Hecuba /storage/nvme6/complete_shakespeare_4096_times':
27,732 itlb_misses.miss_causes_a_walk
13,492 itlb_misses.walk_completed
1,048,087 itlb_misses.walk_pending
0.252038252 seconds time elapsed
明らかに3つすべてが異なります。どのワークロードを実行してもカウンタの相対値は似ているため、パフォーマンスを実行する実際のワークロードは重要ではありません。
私はなぜターンオーバーがボールネットにつながるのか理解していますが、上記はすべてのボールネットが完了していないことを意味するようです。なぜこれですか？
また、保留中の歩行が引き起こされた歩行よりもはるかに大きいのはなぜですか？
最後に、itlbミス率を知りたい場合は、上記のカウンターのどれを使用する必要がありますか？
ベストアンサー1
カウンターは以下の説明:
0x01：（name = miss_causes_a_walk）ページワークを引き起こしたすべてのITLBレベルで見つからない
0x10：（name = walk_pending）コマンドの取得要求で、忙しいページワークの各PMHに対して1サイクルあたり1を計算します。
0x0e: (name=walk_completed) すべての TLB レベルでコードが欠落している場合、ページのナビゲーションは完了します。 (全ページサイズ)
必要なページがページテーブルに実際に記述されていない場合、ページ巡回が完了しない可能性があります。 「存在しない」ページに到達するページ巡回は、失敗したページ巡回として扱われます（推論的でない場合はページ巡回が発生します）。間違って）。
保留中のウォーキングカウンターは、保留中のウォーキングの瞬間数を反映せず、ページをナビゲートするのに必要なサイクル数を計算します。
iTLB損失率を計算するには、通常、最初のカウンタ（合計iTLBクエリ数に相対）を使用します。
また、見ることができますマルチレベルページングのページテーブル巡回に関する追加情報。