Linux 页表是否可能大于物理内存?如果是,表存储在哪里?

Linux 页表是否可能大于物理内存?如果是,表存储在哪里?,linux,operating-system,Linux,Operating System,假设您有一台64位计算机,这意味着64位虚拟地址空间,它有4KB的页面和4GB的物理内存。如果我们像您建议的那样有一个单级页面表,那么它应该在每个进程的每个虚拟页面中包含一个条目 每个虚拟页面一个条目–264个可寻址字节/212个字节/页面=252个页面表条目 一页表条目包含:访问控制位,如页面显示、RW等位+物理页码 4 GB物理内存=232字节 232字节内存/212字节每页=220个物理页 物理页码需要20位 因此,每个页表条目大约有4个字节。20位物理页码约为3字节,访问控制贡献1字节

假设您有一台64位计算机,这意味着64位虚拟地址空间,它有4KB的页面和4GB的物理内存。如果我们像您建议的那样有一个单级页面表,那么它应该在每个进程的每个虚拟页面中包含一个条目

每个虚拟页面一个条目–264个可寻址字节/212个字节/页面=252个页面表条目

一页表条目包含:访问控制位,如页面显示、RW等位+物理页码

4 GB物理内存=232字节

232字节内存/212字节每页=220个物理页

物理页码需要20位

因此,每个页表条目大约有4个字节。20位物理页码约为3字节,访问控制贡献1字节

现在,页表大小=252页表条目*4字节=254字节16 PB

这不仅仅是物理内存,那么我们如何以及在哪里存储页表呢


谢谢大家!

页表可能大于物理内存。您需要做的是将表的一部分分页到辅助存储

有些处理器实际上可以做到这一点。他们通过使用单独的系统和用户页面表来避免明显的鸡和蛋问题。系统页表映射到物理页帧,而用户页表映射到系统空间中的逻辑地址


可能还有其他方法可以实现比我描述的物理内存更大的页表。

我没有检查您的数学,但让我们退一步问一个稍微不同的问题,为什么要映射整个可能的物理地址空间

在具有支持分页的MMU的典型CPU上,只有一小部分物理地址是RAM或MMIO地址。间隔的物理地址的其余部分未使用。通常情况下,如果您将那些不寻址设备的物理地址映射到虚拟地址,然后尝试访问它们,您会遇到某种异常

因此,在实践中,页表的实际大小受到可寻址的RAM和MMIO空间量的限制。如果您有少量RAM,则不需要示例中描述的大量页表。大多数条目都是无效的

相反,如果您的系统确实有大量的RAM消耗了大部分物理地址空间,那么您将有更多的RAM来存储页表


页表消耗所有RAM的另一种方式是使用多个页表或多个虚拟地址映射到同一物理地址的表,但这个问题与该场景无关

我参加这场比赛有点晚了,但有一些评论和澄清

首先,这个问题有点夸张,但目前还没有被严重夸大。原因是,尽管大多数64位体系结构允许将来扩展到64位虚拟地址空间,但据我所知,目前没有一种体系结构支持完整的64位。例如,Xeon服务器目前支持48位。然而,即使是48位VA空间也足以引发问题

VxWizard给出的第二个答案谈到了物理地址空间中的漏洞,在我看来似乎没有抓住要点。由于虚拟寻址的一个要点是拥有比PA更多的VA空间,PA空间中的漏洞与页表的大小无关

现在回到原来的问题。显然,页表的大小可以大于所有物理内存,这显然意味着页表的某些部分可以被调出。但是怎样才能处理TLB失误呢?TLB未命中似乎意味着从页表中取数——如果页表被调出,则必须从磁盘中取数。但是指示要在磁盘中提取的位置的指针被保留。。。在磁盘上的页表中

这不是无限递归的原因是不能将整个页表调出。它的一部分——特别是告诉页面表本身所在位置的部分——无法分页。只要那一部分留在物理内存中,你就没事了

实现这一点的方法有很多。多级页面表可以提供帮助,分离用户空间和内核空间也是如此。但它们都必须满足的主要问题是,物理内存中必须有足够的页表,以便能够在磁盘上找到其余的页表