ベストアンサー
ページサイズは1ページに必要なスペースです（これは非常に簡単です） ）
ここで少し背景を説明するために、ページテーブルは、OSが人工的にシステムで使用可能なメインメモリの合計量を増やします。物理メモリはメモリ内のアドレス（DRAM）にある実際のビットであり、仮想メモリはOSがプロセスに配置して、処理を行うためにどこにあるかを通知する場所です。 2 ^ 34ビットが通常使用されるRAMの中で最も多いという事実にもかかわらず、2 ^ 64ビットのアドレススペースを許可するようなものです。 （2 ^ 32ビットは4ギガバイトなので、2 ^ 34は16GBです。）
現在、ほとんどのデフォルトのページテーブルサイズは4096です。プロセスごとにkbですが、プロセスがより多くのプロセススペースを必要とする場合、ページテーブルエントリの数が増える可能性があります。ページテーブルのサイズは、最初は少量または大量のメモリを割り当てることもできます。通常、ほとんどのプロセスでは4 kbが最適なサイズです。したがって、ページテーブルのエントリサイズは、32ビットアドレス空間内の任意のアドレスを保持するのに正確に適切な量のスペースです。
ここで例を考えてみましょう：32ビット論理アドレス空間を持つシステムを考えてみましょう。このようなシステムのサイズは4KB（212）であるため、ページテーブルは最大100万エントリ（232/212）で構成されます。各エントリが4バイトで構成されていると仮定します。 、各プロセスには、ページテーブルだけで最大4MBの物理アドレス空間が必要になる場合があります。
完全に理解するには？
回答：4バイト（32ビット） ）は、32ビットアドレス空間に任意のアドレスを保持するのに正確に適切な量です。4バイトの100万エントリはそれぞれ4MBになるため、プロセスには最大4MBの物理アドレス空間が必要になる場合があります。
回答
ページta ble は、プロセスごとにオペレーティングシステムによって維持されます。 すべてのプロセスには独自のページテーブルがあります。そのため、ページテーブルにプロセス識別子を格納する必要はありません。ページテーブルは、指定された論理/仮想ページ番号を実際の物理フレーム/ページアドレスにマップします。
メモリ参照の論理アドレスは次の形式です：
論理アドレス： <仮想ページ番号（ p）、オフセット（d）>
ページ番号（仮想ページ番号）は、ページテーブルのルックアップを実行し、マップされている物理フレームのベースアドレスを取得するために使用されます。次に、フレームのベースアドレス（f）がページ（d）へのオフセットと組み合わされて、物理メモリフレームアドレスが次のように取得されます。
f = page-table [p]
物理アドレス： <物理フレームアドレス（f）、オフセット（d）>
ここで、次のシステムについて考えてみましょう。
1.論理アドレス空間：32ビット2.ページサイズ：4KB（2 ^ 12）3。ページテーブルエントリサイズ：4バイト4.物理メモリ：2GB
4に注意してくださいページテーブルエントリのバイトは、物理フレームのベースアドレスとは別に、複数の種類の情報を効果的に格納します。この情報は、メモリ保護（有効/無効ビット）、アクセスの種類（読み取り/書き込み）、ブックキーピングなどに使用できます。物理フレームアドレス（f）を参照しますが、実際には4バイトエントリのこの特定の部分を参照します。
ページテーブルのサイズを計算しましょう：
のサイズページテーブル=（エントリ数*各エントリのサイズ）
上記のパラメータを指定すると、32ビットの論理アドレスは次のように分割されます。
<（2 ^ 32）/（ 2 ^ 12）ページ番号用のビット、ページへのオフセット用の12ビット>または
<ページ番号用の20ビット、ページへのオフセット用の12ビット>。
これで、ページテーブルのエントリ数（仮想ページの総数）が2 ^ 20に達する可能性があると計算できます。したがって、ページテーブルのサイズは次のようになります。
（2 ^ 20）* 4バイト= 4MBのスペース（プロセスあたり）。
これだけのスペースが、すべてのプロセスのページテーブルの物理メモリに必要になります。メインメモリは2GBしかないことを忘れないでください。また、すべてのプロセスのページテーブル用に4MBのスペースを確保するのは得策ではないかもしれません。また、仮想アドレスの多くには、物理ページアドレスがマップされていない可能性があります。 、それでもページテーブルのサイズは大きくなります。仮想ページ番号に「有効な」ビットが設定されていない場合でも、そのためのスロットがページテーブルに存在する必要があります。
共有の場合メモリ、プロセスごとにページテーブルを持つには、そのページへの共有アクセスを持つすべてのプロセスのページテーブルに同じ物理ページのエントリが必要になります。したがって、システムは同じ物理フレームアドレスに対して複数のエントリを保持することになります。物理メモリの使用率はあまり良くありません。
プロセスごとのページテーブルには、仮想アドレスごとに1つのエントリが含まれることも理解できます。したがって、テーブルのサイズは論理/仮想のサイズに比例します。実際には巨大であることが判明する可能性のあるアドレススペース。
私たちの目標は、ページテーブルを格納するために必要な物理メモリの量を削減/最適化することです。反転ページテーブルはそのようなソリューションの1つです。
反転ページテーブルは、すべてのプロセスでオペレーティングシステムによって維持されるグローバルページテーブルです。システム全体にページテーブルが1つしかないため、各プロセスに対応するページテーブルエントリを識別するために、追加情報をページテーブルに格納する必要があります。
物理フレームごとに1つのエントリを格納し、各場所のコンテンツが
これは、仮想ページ番号でルックアップが発生しなくなることを意味します。 pidが「id」に等しく仮想ページ番号が「p」に等しい一致するエントリを見つけるには、テーブル全体をエントリごとに検索する必要があります。一致に対応するインデックスの場所は物理フレームアドレス（f）であり、オフセット（d）と組み合わせると物理アドレスが得られます。
反転したページでそのルックアップ時間を簡単に推測できます。単純なページテーブルと比較すると、テーブルが大幅に高くなる可能性があります。
ただし、テーブルには物理フレームアドレスごとに1つのエントリが格納され、システム全体に1つのページテーブルがあるため、反転ページテーブルで使用されるメモリの量は大幅に削減されました。どのように？
同じパラメータをもう一度検討してください：
1。論理アドレス空間：32ビット2.ページサイズ：4KB（2 ^ 12）3。ページテーブルエントリサイズ：4バイト。 4.物理メモリ：2GB（2 ^ 31）
ページテーブルのエントリ数=物理ページ数=
（2 ^ 31）/（2 ^ 12）= 2 ^ 19の物理ページまたはフレーム。
1バイトのプロセス識別子を使用するとします。各ページテーブルエントリのサイズは次のようになります。
8ビット（PID）+ 20ビット（仮想ページ番号）+ 4ビット（アクセス情報）= 32ビット= 4バイト。
ページテーブルのサイズ=（2 ^ 19）* 4 =システム全体で2MB。
反転ページテーブルのパフォーマンスは通常、ハッシュページテーブルを介して対処されます。ただし、パフォーマンスとは別に、反転ページテーブルを使用することにはもう1つの欠点があります。共有メモリです。
エントリが1つしかないため、物理フレームごとのページテーブルで、仮想ページ番号が1つだけ含まれている場合、同じ物理フレームを異なるプロセスの複数の仮想ページ番号にマップすることはできなくなりました。これを回避する方法はありますが、ここに書き込む詳細はわかりません。 。
出典-オペレーティングシステムの概念（Silberschatz et al）