好吧，如果问题只是“页表的大小是多少？”无论它是否适合物理内存，答案都可以这样计算：
第一个物理记忆。物理内存有 512K 页（512M / 1K）。这需要 19 位来表示每一页。将其添加到 4 位记帐信息中，您将得到 23 位。
Now virtual memory. With a 38-bit address space and a 10-bit (1K) page size, you need 228 entries in your page table.
Therefore 228 page table entries at 23 bits each is 6,174,015,488 bits or 736M.
这是单级 VM 子系统所需的最大大小对于每个过程.
现在，如果您只有 512M 物理 RAM，显然这是行不通的，因此您有几个选择。
您可以减少物理页的数量。例如，只允许一半内存进行分页，而另一半则始终驻留。这将为每个条目节省一位，但实际上不足以产生影响。
增加页面大小，如果可能的话。 38 位地址空间上的 1K 页是页表非常大的原因。例如，我认为 '386 具有 32 位地址空间，使用 4K 页。这将导致一百万个页表条目，远远少于此处所需的 2.6 亿个。
走向多层次。更高级一点，但它基本上意味着页表本身要进行分页。您必须将第一级页表保留在物理内存中，但第二级页表可以根据需要进出。这将极大地降低物理要求，但以速度为代价，因为获取实际进程页面时可能会发生两级页面错误（一级用于辅助分页表，一级用于进程页面）。
让我们仔细看看选项 3。
如果我们允许主页表为 32M，并给每个条目 4 个字节（32 位：只需要 23 位，但我们可以在这里舍入以提高效率），这将允许辅助页表有 8,388,608 个页面。
由于每个辅助页表页都是 1K 长（允许我们以每个 4 字节存储 256 个辅助页表条目），因此我们总共可以寻址 2,147,483,648 个虚拟页。
这将允许 8,192 个完全加载的（即使用其整个 28 位地址空间）进程并排运行，假设您有相当大的磁盘空间来存储非常驻页面。
现在显然主分页表（和VM子系统，可能还有操作系统其余部分的相当一部分）必须始终保持驻留。不能允许您调出其中一个主要页面，因为您很可能需要该页面才能将其带回:-)
但这对于主分页表来说，512M 的驻留成本仅为 32M，比（至少对于一个满载进程而言）736M 要好得多。
