ただし、この方式ではキャッシュのサイズはページサイズより小さいことが必要である。つまり、Intelの4KBページの場合は、キャッシュのサイズは最大4KBにしか出来ない。

もちろん、この方式でも、ページサイズを大きくすればそれに比例してキャッシュサイズも大きくすることができる。昔、メインメモリのサイズが4MBしか無かった時代は、4KBのページで1,024ページであったが、ページを256KBにすると16ページしか無くなってしまう。

そうすると、メモリ管理の自由度が小さくメモリの無駄が多くなってしまうので、当時としては4KBとか8KBのページサイズが適当であった。しかし、現在では少なくとも256MB程度のメインメモリを持っているので、メモリの管理効率の点から言えば、256KBページにしても良いのであるが、OSやアプリケーションプログラムがx86の場合は4KB、SPARCの場合は8KBというページサイズを前提にして作られてしまっているので、基本のページサイズを今更、変えることは現実的に不可能である。ということで、キャッシュを大きくするために、ページサイズを大きくするという手は採れない。

キャッシュを大きく取る1つの手は、セット数を多くすることである。

図5.10 2wayセットアソシアティブキャッシュ

図5.10のように、2wayセットアソシアティブ方式にすると、キャッシュのアクセスに使うアドレスはページ内に収まっており、TLBを通す必要はない。つまり、キャッシュサイズがページサイズに制約されるというのは、1つのwayの範囲内であり、キャッシュ全体の容量はページサイズのway数倍まで大きくすることができる。

Intelのx86プロセサはこの方式を用いており、1次キャッシュが16KBの時代には、4KB x 4way、最近の32KBのキャッシュでは4KB x 8wayの構成をとっている。しかし、この方式ではキャッシュ容量を増やそうとすると、way数を増やす必要があり、チップ面積や消費電力の点で不利である。

ということで、出来ればway数をあまり増やさずに、キャッシュの容量を増やしたい。では、ページサイズよりも1wayのキャッシュのサイズを大きくしたら、どういう問題が起きるのであろうか?

プログラムを実行する場合、まず、OSがディスクからプログラムのバイナリイメージを読み、OS空間に取られたページに書き込んでいく。そして、準備が整うと、それらのページをアプリケーションプロセス用の仮想空間にマッピングするページテーブルを作成して、アプリケーションに実行権を引き渡す。この時、アプリケーションの仮想空間の0ページは、OS空間では何ページになっているかは、その時のOSの都合で決まる。

したがって、図5.11のように、物理空間では同一のページがOS空間では奇数番号のページ、アプリケーション空間では偶数番号のページに割り当てられるということが発生しうる。このように、実体は同じであるが、仮想空間が異なると別の番地になることをVirtual Synonymと言う。まあ、実体は同じであるが、タレントや作家が、本名と芸名やペンネームを持っているようなものである。

図5.11 ページサイズの2倍のキャッシュのアドレス対応

この図5.11の例では、キャッシュの各wayのサイズはページサイズの2倍であり、OS空間の2n+1ページとアプリケーション空間の2mページが同一の物理ページに対応している。しかし、キャッシュの各wayのサイズは2ページ分であるので、緑の偶数番号のページはキャッシュの下位の半分、青の奇数番号のページはキャッシュの上位の半分に対応することになる。

しかし、これではOSが準備したデータをアプリケーションプロセスが読むことが出来ないし、同じ物理アドレスにアクセスしているのに、双方が別のキャッシュラインを使っているとメチャクチャになってしまう。