仮想メモリのページテーブルサイズを決定する
38ビットの仮想バイトアドレス、1 KBのページ、および512 MBの物理メモリを備えた仮想メモリシステムについて考えます。有効ビット、保護ビット、ダーティビット、使用ビットの合計が4ビットで、すべての仮想ページが使用されていると仮定して、このマシンの各プロセスのページテーブルの合計サイズはどれくらいですか？ （ディスクアドレスがページテーブルに格納されていないと仮定します。）
さて、質問が単に「ページテーブルのサイズは？」物理メモリに収まるかどうかに関係なく、答えは次のように計算できます。
最初の物理メモリ。 512Kページの物理メモリ（512M/1K）があります。これには、各ページを表すために19ビットが必要です。これを4ビットのアカウンティング情報に追加すると、23ビットが得られます。
今仮想メモリ。 38ビットのアドレス空間と10ビット（1K）のページサイズでは、228 ページテーブルのエントリ。
したがって、228 それぞれ23ビットのページテーブルエントリは、6,174,015,488ビットまたは736Mです。
これは、単一レベルに必要な最大サイズですVMサブシステムプロセスごとに。
512Mの物理的なRAMしかないので、いくつかのオプションがある場合は、これでうまくいきません。
物理ページの数を減らすことができます。たとえば、メモリの半分だけがページングの対象になるようにし、残りの半分は常に常駐させます。これは、エントリごとに1ビットを節約しますが、違いを生むには十分ではありません。
ページサイズを大きくします可能な場合。 38ビットアドレス空間の1Kページは、非常に分厚いページテーブルの理由です。たとえば、32ビットのアドレス空間を持つ '386は4Kページを使用していると思います。これにより、100万ページのテーブルエントリが生成されます。
マルチレベルに。少し高度ですが、基本的にはページテーブル自体がページングの影響を受けることを意味します。最初のレベルのページテーブルは物理メモリに常駐させる必要がありますが、2番目のレベルは必要に応じて出入りできます。これにより、物理的な要件は大幅に軽減されますが、速度が犠牲になります。実際のプロセスページで2つのレベルのページフォールトが発生する可能性があるためです（1つはセカンダリページングテーブル用、もう1つはプロセスページ用）。
オプション3をもう少し詳しく見てみましょう。
プライマリページングテーブルに32Mを許可し、各エントリに4バイト（32ビット：23のみが必要ですが、ここでは効率を上げるために切り上げることができます）を与えると、セカンダリページテーブルに8,388,608ページが許可されます。
これらのセカンダリページテーブルの各ページは1Kの長さなので（それぞれ4バイトで256のセカンダリページテーブルエントリを保存できます）、合計2,147,483,648個の仮想ページに対応できます。
これにより、非常駐ページを格納するためのディスクスペースのチャンクがかなりあると仮定すると、完全にロードされた（つまり、28ビットのアドレス空間全体を使用して）8,192プロセスを並べて実行できます。
ここで明らかにプライマリページングテーブル（およびVMサブシステム、およびおそらくOSの残りのかなりの部分）は常に常駐している必要があります。次のいずれかをページアウトすることは許可されません。 :-)に戻すためにそのページが必要になる可能性があるため、プライマリページ
ただし、これは、プライマリページングテーブルの512Mのうちわずか32Mの常駐コストであり、（最低でも、1つの完全にロードされたプロセスの）736Mよりはるかに優れています。
ページテーブルのサイズ=ページテーブルエントリの合計数*ページテーブルエントリのサイズ
ステップ1：ページ表でエントリーの数を見つける：
_no of page table entries=virtual address space/page size
=2^38/2^10=2^28
_したがって、ページテーブルには2 ^ 28のエントリがあります
ステップ2：物理メモリのフレームなし：
no of frames in the physical memory=(512*1024*1024)/(1*1024)=524288=2^19
したがって、有効、保護、ダーティ、および合計23ビット= 2.875バイトを使用するには、_19 bits_と追加の_4 bits_が必要です
_size of the page table=(2^28)*2.875=771751936B=736MB
_