[メモリ] TLBキャッシュは魔法の馬ですが、TLBミスをチェックする方法は？

目次

ページテーブルに起因する問題

TLBが誕生しました

TLBミスをチェックする方法

展開

参照

---

オリジナル：https：//blog.csdn.net/zhangyanfei01/article/details/100053533

Linux v2.6.11以降、Linuxで採用される最終的なソリューションは4レベルのページテーブルです。これは、
-PGD：ページグローバルディレクトリ（47-39）、ページグローバルディレクトリ
-PUD：ページ上位ディレクトリ（38-30）、ページ上位ディレクトリ
-PMD：ページミドルディレクトリ（29-21）、ページミドルディレクトリ
-PTE：ページテーブルエントリ（20-12）、ページテーブルエントリ

このように、64ビット仮想空間には次のものが必要です。2^ 9 PGD + 2 ^ 9 PUD + 2 ^ 9 PMD + 2 ^ 9 PTE = 2048ページテーブルデータ構造。現在のページテーブルのデータ構造は8バイトに拡張されています。（2048 * 8 =）16Kのみが（2 ^ 48 =）256Tプロセスアドレス空間をサポートできます。

ページテーブルに起因する問題

プロセッサがMMUを導入した後、命令とデータを読み取るためにメモリに2回アクセスする必要があります。

最初にページテーブルにクエリを実行して物理アドレスを取得し、次に物理アドレスにアクセスして命令とデータを読み取ります。

ページテーブルはメインメモリに格納されるため、プログラムには毎回少なくとも2回のメモリアクセスが必要です（シングルレベルページテーブル）。1回は物理アドレスを取得するためのアクセスで、もう1回はデータを取得するためのアクセスです。

16Kページテーブルデータは256Tアドレス空間アドレス指定をサポートしていますが。ただし、これには追加の問題もあります。ページテーブルはメモリに保存されます。つまり、メモリIOが単なる仮想アドレスから物理アドレスへの変換である場合、メモリに移動してページテーブルを4回チェックし（レベル4）、実際のメモリアクセスをカウントする必要があります。5つのメモリIOが必要です。メモリデータを取得するために!!

TLBが誕生しました

 

TLBの導入によって引き起こされるMMUプロセッサのパフォーマンス低下を減らすために、TLBトランスレーションルックアサイドバッファは「アドレストランスレーションルックアサイドバッファ」と呼ばれ、「高速テーブル」とも呼ばれます。

簡単に言うと、TLBはページテーブルのキャッシュであり、現在アクセスされている可能性が最も高いページテーブルエントリを格納し、その内容は一部のページテーブルエントリのコピーです。TLBがアドレス変換タスクを完了できない場合にのみ、ページテーブルがメモリ内でクエリされます。これにより、ページテーブルクエリによって引き起こされるプロセッサパフォーマンスの低下が軽減されます。

TLBの原則

 

CPUが仮想アドレス/線形アドレスにアクセスする場合、CPUは最初に仮想アドレスの上位20ビットに従ってTLBを検索します（20はx86固有であり、アーキテクチャが異なれば値も異なります）。テーブルに対応するエントリがない場合、それはTLBミスと呼ばれ、対応する物理アドレスは、低速RAMのページテーブルにアクセスして計算する必要があります。同時に、物理アドレスはTLBエントリに格納され、同じ線形アドレスへの後続のアクセスは、TLBヒットと呼ばれるTLBエントリから物理アドレスを直接取得できます。

次のように要約します。

• 1.CPUが仮想アドレスを生成します
• 2. MMUはTLBからページテーブルを取得し、それを物理アドレスに変換します
• 3.MMUは物理アドレスをL1 / L2 / L3 /メモリに送信します
• 4.L1 / L2 / L3 / Memoryはアドレス対応データをCPUに返します

2番目のステップはレジスタのアクセス速度に似ているため、TLBにヒットする可能性がある場合、仮想アドレスから物理アドレスまでの時間オーバーヘッドはほとんど無視できます。TLBの動作メカニズムをより詳細に理解したい場合は、「コンピュータシステムの詳細な理解-第9章仮想メモリ」を参照してください。

x86_32アーキテクチャでTLBがない状況を想像してみてください。リニアアドレスにアクセスするには、最初にPGDからPTEを取得し（最初のメモリアクセス）、PTEからページフレームアドレスを取得し（2番目のメモリアクセス）、最後に物理にアクセスします。アドレスには、合計3つのRAMアクセスが必要です。TLBとTLBヒットがある場合、必要なRAMアクセスは1つだけです。

TLBミスをチェックする方法

TLBキャッシュヒットは重要なので、システムのヒット率をチェックするためのツールは何ですか？本当に

# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-loads,iTLB-load-misses -p $PID

Performance counter stats for process id '21047':

627,809 dTLB-loads

8,566 dTLB-load-misses # 1.36% of all dTLB cache hits

2,001,294 iTLB-loads

3,826 iTLB-load-misses # 0.19% of all iTLB cache hits

iTLB-loadsはiTLB-load-missesよりも大きくても小さくてもかまいません：https ：//stackoverflow.com/questions/49933319/how-to-interpret-perf-itlb-loads-itlb-load-misses

Broadwellプロセッサで、perfはiTLBロードをITLB_MISSES.STLB_HITにマップします。これは、L1 ITLBを見逃すが、すべてのページサイズで統合TLBをヒットするTLBルックアップのイベントを表します。すべてのページサイズで、L1 ITLBと統合TLBの両方を見逃した（ページウォークを引き起こす）TLBルックアップのイベントを表します。したがって、iTLB-load-misssは、iTLB-loadsよりも大きい場合も小さい場合もあります。それらは独立したイベントです。

iTLBとdTLBの意味：https ：//zhengheng.me/2015/11/12/perf-stat/

https://blog.csdn.net/u011630575/article/details/66476165

展開

TLBはそれほど大きくないため、4kのみであり、論理コアによって2つのプロセスが共有されます。したがって、キャッシュミスが発生する可能性があります。また、TLBミスの結果が物理アドレスキャッシュミスの結果よりも深刻になると、最大5つのメモリIOが必要になる場合があります。上記のperfツールを使用して、プログラムのTLBのミスステータスを確認することをお勧めします。ミス率が非常に高い場合は、Linuxで大容量のメモリページを使用できます。PHP7の作成者であるBirdBrotherを含む多くの大物も提案しています。この。これにより、ページテーブルエントリの数が大幅に削減されるため、当然、TLBキャッシュのミス率も削減されます。負担する代償は、ある程度のメモリの浪費です。Linuxでは、大容量メモリページはデフォルトでは開かれません。

参照

• Linuxカーネルの4レベルのページテーブルの進化
• TLBとPCIDとは何ですか？なぜPCIDがあるのですか？Linuxが今それを使い始めているのはなぜですか？
• MMUメモリ管理ユニット

 

パフォーマンス統計メモリ関連のイベント（https://blog.csdn.net/mrpre/article/details/83537311）

perfで検出可能なすべてのイベントは、コマンドperflistを使用して取得できます。

この記事では、メモリ関連のパフォーマンスのいくつかのイベント例を示します

検出プロセスでのページフォールトの数（ページフォールト）
perf stat -e faults ./mem
は、。/ memの実行サイクル中に発生したページフォールトの数をカウントできます。

'./mem'のパフォーマンスカウンター統計：

           100,126の障害                                                      

       0.203315268秒経過し

て実行中のプロセスを検出し、
perf stat -e faults -p $ PIDを使用して実行します。コマンドが中断された後、コマンドの開始から終了までのターゲットプロセスのページフォールト中断の数。コマンドが出力されます。

perfレコードを使用して、
perf record -e faults ./memなど、指定されたイベントのホット機能を検出できます。

perfレポートを使用し
て結果を出力します。

サンプル：655個のイベント「フォールト」、イベント数（約）：100151                                                                               
オーバーヘッドコマンド共有オブジェクトシンボル                                                                                                  
  99.57％mem mem [。] func
   0.35％mem ld-2.17.so [。] _ dl_lookup_symbol_x
   0.06％mem ld-2.17.so [。] _ dl_important_hwcaps
   0.01％mem ld-2.17.so [。] _ dl_start
   0.00％mem ld-2.17.so [。] _ start
   0.00％mem [kernel.vmlinux] [k] __clear_user
   0.00％mem [kernel.vmlinux] [k ] copy_user_enhanced_fast_stringの

原理
カーネルページフォールト割り込みには、ページフォールト割り込みの数をカウントするためのperfフックがあります。

perf_sw_event（PERF_COUNT_SW_PAGE_FAULTS、1、regs、address）;

カーネルソースコードでPERF_COUNT_SW_PAGE_FAULTSを検索します。

プロセスTLB関連のイベントを検出します
perfstat -e dTLB-loads、dTLB-load-misses、iTLB-loads、iTLB-load-misses、L1-icache-load-misses ./mem
または、検出するプロセスIDを指定します
perf stat -e dTLB -loads、dTLB-load-misses、iTLB-loads、iTLB-load-misses、L1-icache-load-misses -p $ PID

$ perf stat -e dTLB-loads、dTLB-load-misses、iTLB-loads、iTLB-load-misses、L1-icache-load-misses ./mem

 './mem'のパフォーマンスカウンター統計：

        89,946,326 dTLB-loads（80.09％）
            17,030 dTLB-load-misss＃すべてのdTLBキャッシュヒットの0.02％（40.47％）
                10 iTLB-loads（39.96％）
               137 iTLB-load-misss＃すべてのiTLBキャッシュヒットの1370.00％（59.80 ％）
            98,113 L1-icache-load-misses（79.65％）

       0.201743107秒の経過時間

はハードウェアイベントであるため、これらの値は、CPUアーキテクチャごとに異なる値を表します。同じことは、dTLBがデータのTLB統計を表し、iTLBが命令のTLB統計を表すことです。

関連する参照ドキュメント：http ：//web.eece.maine.edu/~vweaver/projects/perf_events/perf_event_open.html
————————————————
著作権表示：この記事はCSDNですブロガー「Mrpre」の元の記事は、CC 4.0 BY-SAの著作権表示に準拠しています。再印刷するには、元のソースへのリンクとこのステートメントを添付してください。
元のリンク：https：//blog.csdn.net/mrpre/article/details/83537311