ロードマップでわかる！当世プロセッサー事情 第76回

仮想メモリーを支えるもうひとつのキャッシュ TLB

仮想アドレスと物理アドレスを変換する
Address Translationの基本

　前回はメモリーの階層構造と同様に、複数段階のキャッシュ構成があることを説明した。今回はちょっと見方を変えた話をしたい。まず、キャッシュという形でCPU内部に搭載されている、別のメモリーについて触れよう。

　ご存知の通り、1次キャッシュは通常「ハーバード・アーキテクチャー」と呼ばれる構造に基づき、命令用とデータ用がそれぞれ別に用意される。詳細は後述するが、2次キャッシュや最近では3次キャッシュを搭載するプロセッサーも多くなった。ただ、これらはいずれも「プログラムそのもの、およびプログラムの実行時に利用されるデータ」である。

　「ではそれ以外に何かあるのか？」と言われると、これが結構ある。一番多く利用されるのが「TLB」(Translation Lookaside Buffer)と言われるものだ。これは「仮想記憶」と関係する。WindowsでもLinuxでもいいが、一般に仮想記憶のメカニズムを搭載しているCPUの場合、同時に複数のプログラムが、それぞれ独自の「プロセス」と呼ばれる環境の中で動作することになる。

　このプロセスは、それぞれ独自のメモリー空間が利用でき、(OSによる制限がなければ)32bit CPUならば最大4GB、64bit CPUならさらに大量のメモリー空間を、ほかのプロセス(ほかのプログラム)と分け合うことなく利用できる。硬い言い回しになってしまったが、ようするに図1のような構図だ。

図1 一般的な仮想記憶の仕組み

　例えば、Windows上でExcelとWordとPowerPointを同時に起動したとする。その場合、各々のプログラムは別々のプロセスとして起動される(タスクマネージャーを起動して、プロセスタブを見ればわかりやすい)。各々のプログラムはそれぞれ別々にメモリーが管理される。だから「WordとExcelを同時に動かすと、同じメモリー空間を両方がアクセスしようとして落ちる」なんてことはない(メモリー容量が足らなくて、という話は別)。

　これをうまく管理しているのが、仮想記憶の「Address Translation」(アドレス変換)という機能である。最終的には、どのプロセスが使うメモリーも物理的なメモリーに割り当てられるが、この「仮想アドレス→物理アドレス」の変換をする機能がこれだ。これにより、各プロセスは何も考えなくても、自動的に物理メモリーを利用可能になっている。

　さて、このAddress Translationは当然のことながら、ハードウェアで実装されている。例えばx86の32bitモードで、ページサイズが4KBの場合は、下の画像のような構造となる。ソフトウェアでこれを行なっていたら、Address Translationに猛烈な時間が掛かってしまうから、ハードでやるのは当然だ。

x86の32bitモード/ページサイズ4KBでのAddress Translationの仕組み。「Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1」より引用

　問題は、このAddress Translationに対して、「何がどこに当たる」を教えるのは誰かである。図1を元に説明しよう。プロセスAの仮想アドレス#01～#04は、それぞれ物理メモリーの#001、#009、#013、#003に格納されている。この「どの仮想アドレスがどの物理アドレスに対応しているか」をAddress Translationに教えてやらなければならない。

　これを行なうのが「ページテーブル」である。図1では中央下の赤枠部分全体をページテーブルと呼び、個々の項目を「PTE」(ページテーブルエントリ)と呼ぶ。このPTEが格納されたページテーブルを参照することによって、Address Translationは仮想アドレスに対応した物理メモリーのアドレスがわかる。

　次なる問題は、ページテーブルは物理的にどこに置かれるかだ　答えはメモリーである。例えば1GBのメモリーを4KBページで管理したとする。仮に1GBすべてを仮想記憶で管理したとすると、PTEは全部で26万2144個にもなる。PTEのサイズは1個あたり4Byteなので、これだけで1MBものサイズになる。メモリー4GBなら4MBになるし、64bitモードだとさらに大きくなる。

　最近のCPUならプロセスが微細化されているから、この程度でも内蔵可能だが、Intel 486なんて、たった8KBのキャッシュを設けるのにトランジスターの3割ほどを割いていた。数MBものテーブルを内蔵するのは不可能である。従って、必然的にページテーブルはメモリーに置かざるをえない。