仮想メモリを実装するためのコアメカニズムとしてページングを使用すると、パフォーマンスのオーバーヘッドが高くなる可能性があります。ページングを使用するため、メモリアドレス空間を多数の固定サイズのユニット（ページ）に分割し、これらのユニットのアドレスマッピング情報を記録する必要があります。これらのマッピング情報は通常物理メモリに格納されるため、仮想アドレスを変換するとき、ページングロジックは追加のメモリアクセスを必要とします。命令がフェッチされ、明示的にロードまたは保存されるたびに、許容できないほど遅い変換情報を取得するために、メモリの追加の読み取りが必要になります。したがって、次の問題に直面します。
重要な質問：アドレス変換を高速化する方法
どのようにして仮想アドレス変換を高速化し、可能な限り追加のメモリアクセスを回避できますか？どのようなハードウェアサポートが必要ですか？オペレーティングシステムはそれをどのようにサポートすべきですか？
何かをより速くするために、オペレーティングシステムは通常いくつかの助けを必要とします。多くの場合、ヘルプはオペレーティングシステムの古くからの友人、ハードウェアから提供されます。頻繁に発生する仮想アドレスから物理アドレスへの変換のためのハードウェアキャッシュである、いわゆる（歴史的な理由により[CP78]）アドレス変換バイパスバッファーメモリ（translation-lookasideバッファー、TLB [CG68、C95]）を増やす必要があります。したがって、より適切な名前はアドレス変換キャッシュです。各メモリアクセスについて、ハードウェアは最初にTLBをチェックして、予想される変換マッピングがあるかどうかを確認し、ある場合は、ページテーブル（すべての変換マッピングがある）にアクセスせずに（すぐに）変換を完了します。TLBにより、パフォーマンスが大幅に向上します。実際、仮想メモリが可能になります[C95]。
19.1 TLBの基本アルゴリズム
図19.1は、ハードウェアが仮想アドレス変換を処理する方法を示す一般的なフレームワークを示しています。単純な線形ページテーブル（線形ページテーブル、つまりページテーブルは配列です）とハードウェア管理のTLB（ハードウェア管理のTLB、つまりハードウェアが多くの役割を担っています）ページテーブルアクセスの責任。詳細については後述します）。
1 VPN = (VirtualAddress & VPN_MASK) >> SHIFT
2 (Success, TlbEntry) = TLB_Lookup(VPN)
3 if (Success == True) // TLB Hit
4 if (CanAccess(TlbEntry.ProtectBits) == True)
5 Offset = VirtualAddress & OFFSET_MASK
6 PhysAddr = (TlbEntry.PFN << SHIFT) | Offset
7 AccessMemory(PhysAddr)
8 else
9 RaiseException(PROTECTION_FAULT)
10 else // TLB Miss
11 PTEAddr = PTBR + (VPN * sizeof(PTE))
12 PTE = AccessMemory(PTEAddr)
13 if (PTE.Valid == False)
14 RaiseException(SEGMENTATION_FAULT)
15 else if (CanAccess(PTE.ProtectBits) == False)
16 RaiseException(PROTECTION_FAULT)
17 else
18 TLB_Insert(VPN, PTE.PFN, PTE.ProtectBits)
19 RetryInstruction()図19.1 TLB制御フローアルゴリズム
ハードウェアアルゴリズムの一般的なフローは次のとおりです。まず仮想アドレスからページ番号（VPN）を抽出し（図19.1、1行目を参照）、次にTLBにVPNの変換マッピングがあるかどうかを確認します（2行目）。もしそうなら、TLBヒットがあります。つまり、TLBにはそのページの変換マップがあります。成功！次に、関連するTLBエントリからページフレーム番号（PFN）を取得し、それを元の仮想アドレスのオフセットと組み合わせて目的の物理アドレス（PA）を形成し、メモリにアクセスします（5〜7行目）。保護チェックは失敗しませんでした（4行目）。
CPUがTLBで変換マップを見つけられない場合（TLBミス）、いくつかの作業があります。この例では、ハードウェアがページテーブルにアクセスして変換マップを見つけ（行11〜12）、変換マップを使用してTLBを更新します（行18）。ただし、仮想アドレスが有効であり、関連するアクセス権がある（行13、 15行）。上記の一連の操作は、主にページテーブルにアクセスするために追加のメモリ参照が必要なため（12行目）、コストがかかります。最後に、TLBの更新が成功すると、システムは命令を再試行しますが、この時点でTLBにこの変換マッピングがあり、メモリ参照が迅速に処理されます。
TLBは他のキャッシュに似ていますが、通常の状況では、変換マッピングはキャッシュにあります（つまり、ヒットします）。その場合、TLBプロセッサコアの近くではデザインのアクセス速度が非常に速いため、追加されるオーバーヘッドはわずかです。TLBが失敗すると、多くのページングオーバーヘッドが発生します。変換マップを見つけるためにページテーブルにアクセスする必要があるため、追加のメモリ参照（ページテーブルがより複雑な場合はさらに多く）が発生します。これが頻繁に発生する場合は、プログラムの速度が大幅に低下します。ほとんどのCPU命令と比較して、メモリアクセスは高価であり、TLBミスはより多くのメモリアクセスを引き起こします。したがって、TLBミスをできるだけ回避したいと考えています。
19.2例：配列へのアクセス
TLBの動作を明確にするために、簡単な仮想アドレストレースを見て、TLBがパフォーマンスを向上させる方法を見てみましょう。この例では、10個の4バイト整数の配列があり、開始仮想アドレスが100であるとします。さらに、ページサイズが16Bの小さな8ビットの仮想アドレス空間があるとします。仮想アドレスを4ビットVPN（16の仮想メモリページ）と4ビットオフセット（各ページに16バイト）に分割できます。
図19.2例：小さなアドレス空間の配列
図19.2は、システム内の16個の16バイトページでのこの配列のレイアウトを示しています。ご覧のとおり、配列の最初の項目（a [0]）は（VPN = 06、offset = 04）から始まり、このページには3つの4バイト整数のみが格納されています。アレイは次のページ（VPN = 07）に続き、次の4つのアイテム（a [3]…a [6]）があります。10要素配列の最後の3項目（a [7]…a [9]）は、アドレス空間の次のページ（VPN = 08）にあります。
次のCプログラムのように、配列の各要素にアクセスする単純なループについて考えてみましょう。
int sum = 0;
for (i = 0; i < 10; i++) {
sum += a[i];
}簡単にするために、ループによって生成されるメモリアクセスは配列のみを対象としています（変数iとsum、および命令自体は無視されます）。最初の配列要素（a [0]）にアクセスすると、CPUには仮想メモリアドレス100が読み込まれます。ハードウェアはそこからVPN（VPN = 06）を抽出し、それを使用してTLBをチェックして有効な変換マッピングを見つけます。これがプログラムが配列に初めてアクセスしたときであり、その結果がTLBミスであるとします。
次にa [1]にアクセスしてください。ここで朗報です。TLBヒットです！配列の2番目の要素は最初の要素の後にあるため、同じページにあります。配列の最初の要素にアクセスしたときにこのページにすでにアクセスしているため、このページの変換マップはTLBにキャッシュされます。したがって、正常にヒットします。a [0]およびa [1]と同じページ上にあるため、a [2]へのアクセスも成功（再度ヒット）します。
残念ながら、プログラムがa [3]にアクセスすると、TLBミスが発生します。ただし、次のいくつかのアイテム（a [4]…a [6]）は、メモリ内の同じページにあるため、すべてTLBにヒットします。
最後に、a [7]にアクセスすると、最後のTLBミスが発生します。システムは再度ページテーブルを検索し、物理メモリ内のこの仮想ページの場所を特定し、それに応じてTLBを更新します。最後の2回の訪問（a [8]、a [9]）はこのTLB更新の恩恵を受けました。ハードウェアがTLBで変換マッピングを検索したところ、両方にヒットしました。
これらの10個のアクセス操作（ミス、ヒット、ヒット、ミス、ヒット、ヒット、ヒット、ミス、ヒット、ヒット）におけるTLBの動作を要約しましょう。ヒット数を合計訪問数で割ると、TLBヒット率は70％になります。これはそれほど高くはありませんが（実際、ヒット率を100％に近づけたいと考えています）、ゼロではありません。ゼロであると驚きます。プログラムがアレイにアクセスするのはこれが初めてですが、TLBは空間的な局所性によりパフォーマンスを向上させます。配列の要素は複数のページに密接に格納されている（つまり、空間的に近接している）ため、ページの最初の要素にアクセスするだけでTLBミスが発生します。
この例の結果に対するページサイズの影響にも注意してください。ページサイズが2倍になると（16バイトではなく32バイト）、配列アクセスで発生するミスが少なくなります。一般的なページのサイズは通常4KBです。この場合、アレイベースの集中的なアクセスで優れたTLBパフォーマンスが実現し、各ページアクセスで1回のミスしか発生しません。
TLBのパフォーマンスについて最後のポイントが1つあります。このサイクルの直後にプログラムがアレイに再度アクセスした場合、TLBが必要な変換マッピングをキャッシュするのに十分な大きさであると仮定すると、より良い結果が得られます：ヒット、ヒット、ヒット、ヒット、ヒット、ヒット、ヒット、ヒット、ヒット、ヒット、ヒット。この場合、短時間で再びメモリアイテムを参照する一時的な局所性により、TLBヒット率が高くなります。他のキャッシュと同様に、TLBの成功は空間的および時間的局所性に依存しています。プログラムがこのような局所性を示す場合（多くのプログラムがそうであるように）、TLBヒット率は高くなる可能性があります。
ヒント：可能な限りキャッシュを使用してください
キャッシュは、コンピュータシステムの最も基本的なパフォーマンス改善手法の1つであり、「一般的な状況を高速化」するために何度も使用されます[HP06]。ハードウェアキャッシュの背後にある考え方は、命令とデータ参照の局所性を利用することです。通常、局所性には2つのタイプがあります。時間的局所性と空間的局所性です。一時的な局所性とは、最後にアクセスされた命令またはデータ項目がすぐに再びアクセスされる可能性があることを意味します。ループ変数またはループ内の命令について考えてください。それらは何度も繰り返しアクセスされます。空間的局所性とは、プログラムがメモリアドレスxにアクセスすると、xに隣接するメモリにすばやくアクセスできることを意味します。ある配列をトラバースし、次々と要素にアクセスすることを考えてください。もちろん、これらの特性は、絶対的な法則ではなく、プログラムの特性に依存しますが、経験則に似ています。
ハードウェアキャッシュは、それが命令、データ、またはアドレス変換（TLBなど）のいずれであっても、局所性を利用してメモリのコピーを小さくて高速なオンチップメモリに格納します。プロセッサは、要求を満たすために（遅い）メモリにアクセスする必要はなく、キャッシュ内に近くにコピーがあるかどうかを最初に確認できます。存在する場合、プロセッサは非常に高速に（たとえば、いくつかのCPUクロック内で）アクセスでき、メモリへのアクセスに多くの時間（多くのナノ秒）を費やすことを回避できます。
あなたは疑問に思うかもしれません：TLBのようなキャッシュはとても良いので、もっと大きなキャッシュを作ってすべてのデータを保持してみませんか？物理学の法則のように、ここでより基本的な法則に遭遇したのは残念です。すばやくキャッシュしたい場合は、光の速度やその他の物理的な制限が影響するため、小さくする必要があります。大容量のキャッシュは処理速度が遅いため、目標を達成できません。したがって、使用できるのは小さく高速なキャッシュのみです。残りの問題は、キャッシュを有効に活用してパフォーマンスを向上させる方法です。
19.3 TLBミスに対処するのは誰か
答えなければならない質問が1つあります。TLBミスを処理するのは誰ですか？2つの答えがあるかもしれません：ハードウェアまたはソフトウェア（オペレーティングシステム）。以前のハードウェアには、複雑な命令セット（CISC（Complex-Instruction Set Computer）と呼ばれることもあった）があり、ハードウェアを構築した人々は、オペレーティングシステムで作業した人々を信頼していませんでした。したがって、ハードウェアはTLBミスの処理を完全に担当します。これを行うには、ハードウェアはメモリ内のページテーブルの正確な位置（図19.1の行11で使用されているページテーブルベースレジスタを介して）とページテーブルの正確なフォーマットを知っている必要があります。ミスが発生すると、ハードウェアはページテーブルを「トラバース」し、正しいページテーブルエントリを見つけ、目的の変換マップをフェッチし、それを使用してTLBを更新し、命令を再試行します。この「古い」アーキテクチャには、ハードウェア管理用のTLBがあります。例は、固定マルチレベルページテーブルを使用するx86アーキテクチャです（詳細については第20章を参照）。現在のページテーブルは、CR3レジスタ[I09 ]。
より近代的なアーキテクチャ（たとえば、MIPS R10k [H93]、SunのSPARC v9 [WG00]）は、縮小命令セットコンピュータ、縮小命令セットコンピュータ、RISCであり、いわゆるソフトウェア管理TLB（ソフトウェア管理TLB）があります。 ）。TLBミスが発生すると、ハードウェアシステムは例外をスローし（図19.3、11行目を参照）、現在の命令フローを一時停止し、特権レベルをカーネルモードに上げ、トラップハンドラーにジャンプします。次に、ご想像のとおり、このトラップハンドラーはTLBミスを処理するオペレーティングシステムのコードの一部です。このコードを実行すると、ページテーブルで変換マップが検索され、TLBが特別な「特権」命令で更新され、トラップから戻ります。このとき、ハードウェアは命令を再試行します（TLBヒットの原因）。
1 VPN = (VirtualAddress & VPN_MASK) >> SHIFT
2 (Success, TlbEntry) = TLB_Lookup(VPN)
3 if (Success == True) // TLB Hit
4 if (CanAccess(TlbEntry.ProtectBits) == True)
5 Offset = VirtualAddress & OFFSET_MASK
6 PhysAddr = (TlbEntry.PFN << SHIFT) | Offset
7 Register = AccessMemory(PhysAddr)
8 else
9 RaiseException(PROTECTION_FAULT)
10 else // TLB Miss
11 RaiseException(TLB_MISS)図19.3 TLB制御フローアルゴリズム（オペレーティングシステム処理）
次に、いくつかの重要な詳細について説明します。まず、ここでのトラップからの戻り命令は、システムコールを処理する前述のトラップからの戻りとは少し異なります。後者の場合、トラップからの復帰は、オペレーティングシステムがトラップされた後も、命令の実行を継続する必要があります。関数呼び出しからの復帰と同様に、呼び出し後もステートメントを実行し続けます。前者の場合、TLBミストラップから戻った後、ハードウェアはトラップを引き起こした命令から実行を継続する必要があります。したがって、この再試行により、命令は再度実行されますが、今回はTLBにヒットします。したがって、トラップまたは例外の原因に応じて、システムはカーネルに入るときに別のプログラムカウンターを保存して、将来正しく実行し続けることができるようにする必要があります。
次に、TLBミス処理コードを実行するとき、オペレーティングシステムは、TLBミスを引き起こす無限の再帰を回避するために特に注意する必要があります。多くの解決策があります。たとえば、TLBミストラップハンドラーを物理メモリに直接配置できます（アドレストランスレーションなしでは、マッピングされません（マッピングされません）。）または、いくつかのアイテムをTLBに保持し、永続的で有効なアドレス変換を記録し、永続的アドレス変換スロットブロックの一部を処理コード自体に残します。これらの有線アドレス変換は常にTLBにヒットします。
ソフトウェア管理方法の主な利点は柔軟性です。オペレーティングシステムは、ハードウェアを変更することなく、任意のデータ構造を使用してページテーブルを実装できます。別の利点は単純さです。TLB制御フロー（図19.1の行11〜19と比較して、図19.3の行11を参照）から、ハードウェアはミスに対して多くの作業を行う必要がなく、例外をスローし、オペレーティングシステムのミス処理を行うことがわかります。残りはプログラムが処理します。
補足：RISCおよびCISC
1980年代には、コンピュータアーキテクチャの分野で白熱した議論がありました。1つはCISCキャンプ、つまり複雑な命令セットコンピューティング（複雑な命令セットコンピューティング）で、もう1つはRISC、つまり縮小命令セットコンピューティング（縮小命令セットコンピューティング）[PS81]です。RISCキャンプの代表は、バークレーのデビッドパターソン氏とスタンフォードのジョンヘネシー氏（非常に有名な著書[HP06]を書いている）ですが、ジョンコック氏は後にRISC [CM00]の初期の作品でチューリング賞を受賞しました。
CISC命令セットは多くの命令を持つ傾向があり、各命令はより強力です。たとえば、2つのポインタと1つの長さを受け入れ、いくつかのバイトをソースからターゲットにコピーする文字列コピーが表示される場合があります。CISCの背後にある考え方は、命令は高レベルのプリミティブである必要があるということです。これにより、アセンブリ言語自体が使いやすくなり、コードがよりコンパクトになります。
RISC命令セットは正反対です。RISCの背後にある重要な点は、命令セットが実際にはコンパイラーの最終目標であり、すべてのコンパイラーが実際には、高性能コードの生成に使用できる少数の単純なプリミティブを必要とすることです。したがって、RISCの擁護者は、不要なもの（特にマイクロコード）をハードウェアからできるだけ削除し、残りのものはシンプルで統一された高速なものにする必要があると主張しています。
初期のRISCチップは大幅に高速であったため、大きな影響を及ぼしました[BC91]。人々は多くの論文を書き、いくつかの関連会社が次々と設立されました（MIPSやSunなど）。しかし、時間の経過とともに、IntelなどのCISCチップメーカーは、初期のパイプラインステージを追加して複雑な命令をいくつかのマイクロ命令に変換し、RISCのように実行できるようにするなど、RISCチップの多くの利点を採用しています。これらの革新と各チップのトランジスタ数の増加により、CISCは競争力を維持することができました。論争はようやく収まり、今では両方のタイプのプロセッサが非常に高速に実行できます。
19.4 TLBコンテンツ
ハードウェアTLBの内容を詳しく見てみましょう。一般的なTLBには32、64、または128の項目があり、完全に関連付けられています。基本的に、これはアドレスマップがTLBのどこにでも存在する可能性があり、ハードウェアがTLBを並列に検索して目的の変換マップを見つけることを意味します。TLBエントリの内容は次のようになります。
VPN ｜ PFN ｜その他のビット
VPNとPFNはTLBに同時に存在することに注意してください。これは、アドレスマッピングがどこにでも現れる可能性があるためです（ハードウェアの用語では、TLBは完全結合キャッシュと呼ばれます）。ハードウェアはこれらの項目を並行して検索し、一致するかどうかを確認します。
補足：TLBの有効ビット！=ページテーブルの有効ビット
よくある間違いは、TLBの有効ビットとページテーブルの有効ビットを混同することです。ページテーブルで、ページテーブルエントリ（PTE）が無効としてマークされている場合、そのページはプロセスによる使用を要求されておらず、通常実行中のプログラムはアドレスにアクセスできません。プログラムがそのようなページにアクセスしようとすると、オペレーティングシステムに分類され、オペレーティングシステムがプロセスを強制終了します。
TLBの有効ビットは異なります。TLBアイテムが有効なアドレスマッピングであるかどうかを示すだけです。たとえば、システムが起動すると、ここにはキャッシュされたアドレス変換マップがないため、すべてのTLBエントリは通常無効な状態に初期化されます。仮想メモリが有効になると、プログラムが実行を開始し、独自の仮想アドレスにアクセスすると、TLBがゆっくりと満たされるため、有効なアイテムがすぐにTLBを満たします。
TLB有効ビットは、システムコンテキストの切り替えで重要な役割を果たします。これについては、後で詳しく説明します。すべてのTLB項目を無効に設定することにより、システムは、実行されるプロセスが前のプロセスの仮想アドレスから物理アドレスへの変換マッピングを誤って使用しないようにすることができます。
さらに興味深いのは「その他のビット」です。たとえば、TLBには通常、アイテムが有効な変換マップであるかどうかを識別するために使用される有効なビットがあります。通常、ページにアクセス権があるかどうかを識別するための保護ビットがいくつかあります。たとえば、コードページは読み取り可能および実行可能であると識別され、ヒープのページは読み取り可能および書き込み可能であると識別されます。アドレス空間識別子（アドレス空間識別子）、ダーティビットなど、他のビットがあります。詳細は以下で紹介します。
19.5コンテキスト切り替え中のTLB処理
TLBを使用すると、プロセス間の切り替え（したがってアドレス空間の切り替え）時に、いくつかの新しい問題に直面します。具体的には、TLBに含まれる仮想アドレスから物理アドレスへのマッピングは、現在のプロセスでのみ有効であり、他のプロセスでは意味がありません。したがって、プロセス切り替えが発生した場合、ハードウェアまたはオペレーティングシステム（あるいはその両方）は、実行しようとしているプロセスが前のプロセスのアドレスマップを誤って読み取らないように注意する必要があります。
この状況をよりよく理解するために、例を見てみましょう。プロセス（P1）が実行されている場合、TLBがそのプロセスに有効なアドレスマッピング、つまりP1のページテーブルをキャッシュすると想定します。この例では、P1の仮想ページ番号10が物理フレーム番号100にマップされているとします。
この例では、別のプロセス（P2）があり、オペレーティングシステムがコンテキスト切り替えを実行してP2を実行することをすぐに決定するとします。ここでは、Ｐ２の仮想ページ番号１０が物理フレーム番号１７０にマッピングされているものとする。これら2つのプロセスのアドレスマッピングがTLBにある場合、TLBの内容を表19.1に示します。
上記のTLBには明らかに問題があります。VPN10はPFN 100（P1）およびPFN 170（P2）に変換されますが、ハードウェアはどのアイテムがどのプロセスに属しているかを認識できません。したがって、TLBを正しく効率的に複数のプロセスにまたがる仮想化をサポートするために、いくつかの作業を行う必要があります。したがって、重要な質問は次のとおりです。
重要な質問：プロセスの切り替え中にTLBのコンテンツを管理する方法
プロセス間コンテキストスイッチが発生した場合、TLB内の前のプロセスのアドレスマッピングは、プロセスを実行しても意味がありません。この問題を解決するには、ハードウェアまたはオペレーティングシステムで何をする必要がありますか？
この問題にはいくつかの解決策があります。1つの方法は、コンテキストの切り替え中にTLBを単純にフラッシュして、新しいプロセスが実行される前にTLBが空になるようにすることです。ソフトウェア管理TLBシステムの場合は、コンテキストスイッチが発生したときに明示的な（特権付き）命令を使用して行うことができます。ハードウェア管理TLBの場合、ページテーブルベースレジスタの内容が変更されたときにTLBをクリアできます（オペレーティングシステムは、コンテキストの切り替え中にページテーブルベースレジスタ（PTBR）の値を変更する必要があることに注意してください）。どちらの場合も、クリア操作はすべての有効なビット（有効）を0に設定し、本質的にTLBをクリアします。
コンテキストの切り替え中にTLBをクリアすることは実行可能なソリューションであり、プロセスは誤ったアドレスマッピングを読み取ることはありません。ただし、一定のオーバーヘッドがあります。プロセスが実行されるたびに、データとコードページにアクセスすると、TLBミスがトリガーされます。オペレーティングシステムがプロセスを頻繁に切り替える場合、このオーバーヘッドは高くなります。
このオーバーヘッドを削減するために、一部のシステムはハードウェアサポートを追加して、クロスコンテキストスイッチングTLB共有を実現しています。たとえば、システムによっては、TLBにアドレススペース識別子（ASID）を追加します。ASIDはプロセスID（PID）と考えることができますが、通常はPIDよりもビット数が少なくなっています（PIDは通常32ビットで、ASIDは通常8ビットです）。
上記のTLBを例として取り、ASIDを追加する場合、ASIDフィールドを使用して区別できないアドレスマッピングを区別する限り、異なるプロセスがTLBを共有できることは明らかです。表19.2に、ASIDフィールドを追加した後のTLBを示します。
表19.2 ASIDフィールドを追加した後のTLB
したがって、アドレススペース識別子を使用すると、TLBは競合することなく、異なるプロセスのアドレススペースマッピングを同時にキャッシュできます。もちろん、ハードウェアはアドレス変換を実行するために現在実行中のプロセスを認識する必要があるため、オペレーティングシステムはコンテキスト切り替え中に特定の特権レジスタを現在のプロセスのASIDとして設定する必要があります。
さらに、別の状況について考えたことがあるかもしれません。TLBの2つは非常に似ています。表19.3では、2つの異なるプロセスに属する2つのアイテムが2つの異なるVPNを同じ物理ページにポイントしています。
これは、2つのプロセスが同じ物理ページ（たとえば、コードセグメントのページ）を共有している場合に発生する可能性があります。上記の例では、プロセスP1とプロセスP2は物理ページ101を共有していますが、P1はその仮想ページ10をこの物理ページにマップし、P2はその仮想ページ50を物理ページにマップしています。（バイナリーまたは共有ライブラリー内の）共有コード・ページは、物理ページの使用を減らし、それによってメモリーのオーバーヘッドを減らすので便利です。
19.6 TLB交換戦略
TLBには、他のキャッシュと同様に、考慮すべきもう1つの問題、つまりキャッシュの交換があります。具体的には、TLBに新しいアイテムが挿入されると、古いアイテムが置き換えられる（置き換えられる）ため、問題は次のとおりです。
重要な質問：TLB交換戦略の設計方法
TLBに新しいアイテムを追加する場合、どの古いアイテムを置き換える必要がありますか？もちろん、目標はTLBミス率を減らす（またはヒット率を上げる）ことにより、パフォーマンスを向上させることです。
ディスクへのページスワップアウトの問題について説明するときに、この戦略を詳しく検討します。ここでは、いくつかの典型的な戦略を簡単に指摘します。一般的な戦略は、最も最近使用された（LRU）アイテムを置き換えることです。LRUは、メモリ参照ストリームの局所性を利用しようとしますが、最近使用されていないアイテムが適切なスワップアウト候補であると想定しています。別の典型的な戦略は、ランダム（ランダム）戦略です。つまり、交換するアイテムをランダムに選択します。この戦略は単純で、極端な状況を回避できます。たとえば、プログラムはループでn +1ページにアクセスしますが、TLBサイズはnページしか格納できません。現時点では、メモリにアクセスするたびにTLBミスがトリガーされるため、一見「合理的」なLRU戦略は不当に動作します。この場合、ランダム戦略の方がはるかに優れています。
19.7実際のシステムのTLBエントリ
最後に、実際のTLBについて簡単に説明します。この例は、ソフトウェアを使用してTLBを管理する最新のシステムであるMIPS R4000 [H93]によるものです。図19.4は、少し簡略化したMIPS TLB用語を示しています。
図19.4 MIPSのTLBアイテム
MIPS R4000は、ページサイズが4KBの32ビットアドレス空間をサポートします。したがって、一般的な仮想アドレスでは、20ビットのVPNと12ビットのオフセットが表示されることが予想されます。ただし、TLBで確認できるように、19ビットVPNしかありません。実際、ユーザーアドレスはアドレス空間の半分しか占めていません（残りはカーネル用に予約されています）。したがって、19ビットのVPNのみが必要です。VPNは最大24ビットの物理フレーム番号（PFN）に変換されるため、最大64GBの物理メモリ（224個の4KBメモリページ）を持つシステムをサポートできます。
MIPS TLBには、興味深いマーカーもいくつかあります。たとえば、グローバルページ（グローバル、G）は、このページがすべてのプロセスによってグローバルに共有されているかどうかを示すために使用されます。したがって、グローバルポジションが1の場合、ASIDは無視されます。また、オペレーティングシステムがプロセススペースを区別するために使用する8ビットASIDも確認しました（上記を参照）。ここで質問です：実行中のプロセスの数が256（28）を超えるとどうなりますか？最後に、ハードウェアがページをキャッシュする方法を決定する3つのコヒーレンスビット（Coherence、C）が表示されます（そのうちの1つはこの本の範囲を超えています）、ダーティビット（ダーティ）は、ページに新しいデータが書き込まれているかどうかを示します（使用法は後で紹介されます。有効ビット（有効）は、アイテムのアドレスマッピングが有効かどうかをハードウェアに通知します。さまざまなページサイズをサポートするために、図19.4に示されていないページマスクフィールドもあります。後で、大きなページが役立つ理由について説明します。最後に、64ビットの一部は未使用です（図19.4の灰色の部分）。
MIPS TLBには通常32アイテムまたは64アイテムがあり、それらのほとんどはユーザープロセス用に提供され、一部はオペレーティングシステム用に予約されています。オペレーティングシステムは、監視レジスタを設定して、ハードウェアに予約する必要があるTLBスロットの数をハードウェアに通知できます。これらの予約された変換マッピングは、オペレーティングシステムがクリティカル時に使用するコードとデータに使用されます。このような場合、TLBミスは問題を引き起こす可能性があります（たとえば、TLBミスハンドラーで）。
MIPSのTLBはソフトウェアによって管理されるため、システムはTLBを更新するためのいくつかの指示を提供する必要があります。MIPSは、指定された変換マッピングがTLBにあるかどうかを見つけるために使用されるTLBP、TLBの内容を指定されたレジスタに読み込むために使用されるTLBR、指定されたTLBアイテムを置き換えるために使用されるTLBWI、TLBWRの4つの命令を提供します。 、TLBアイテムをランダムに置き換えるために使用されます。オペレーティングシステムは、これらの命令を使用してTLBの内容を管理できます。もちろん、これらの指示は特権的な指示であり、これは重要です。ユーザープログラムがTLBの内容を任意に変更できる場合、どのようなひどいことが起こるか想像できます。
ヒント：RAMは必ずしもRAMではありません（Culler's Law）
ランダムアクセスメモリ（RAM）は、RAMの任意の部分に高速でアクセスできることを意味します。RAMをこのように考えることは一般的に正しいことですが、TLBなどのハードウェア/オペレーティングシステム機能のため、一部のメモリページ、特にTLBによってキャッシュされていないページへのアクセスは負荷が高くなります。したがって、この実装トリックを覚えておくことをお勧めします。RAMは常にRAMであるとは限りません。時々、アドレススペースへのランダムアクセス、特にTLBによってキャッシュされていないページは、重大なパフォーマンスの損失を引き起こす可能性があります。私のメンターの1人であるDavid Cullerは、TLBが多くのパフォーマンス問題の原因であると指摘していたため、この法律を彼の名にちなんでCuller's Lawと名付けました。
この記事は、「オペレーティングシステムの概要」からの引用です。
この本は、仮想化、同時実行性、持続性の3つの主要な概念に焦点を当て、すべての最新システム（スケジューリング、仮想メモリ管理、ディスクおよびI / Oサブシステム、ファイルシステムを含む）の主要コンポーネントを紹介します。この本は、仮想化、並行性、永続性に関する3つの部分に分かれた50の章で構成されています。著者は、導入されたテーマの概念を対話の形で紹介し、機知に富んだ滑稽な執筆も含まれています。これにより、読者が仮想化、並行性、オペレーティングシステムの永続性の原理を理解できるようになります。
この本の内容は包括的であり、実際の実行可能なコード（疑似コードではない）を提供します。また、対応する演習も提供します。これは、カレッジや大学の関連専攻の教師が教育を実施したり、大学生が自習を行ったりするのに非常に適しています。
この本には次の特徴があります。
●テーマは目立ち、オペレーティングシステムの仮想化、同時実行性、持続性の3つの主要なテーマ要素を密接に取り囲んでいます。
●会話の背景を紹介し、質問し、原則を説明し、実践的な実践を促します。
●読者の知識を広げ、関心を高めるための多くの「補足」と「ヒント」が含まれています。
●疑似コードの代わりに実際のコードを使用して、読者がオペレーティングシステムをより深く完全に理解できるようにします。
●課題、シミュレーション、プロジェクトなどの多くの学習方法を提供して、読者に実践を促します。
●教師に補助的な教育リソースを提供します。