Memory 为什么页表条目的大小仅由主内存大小决定?

Memory 为什么页表条目的大小仅由主内存大小决定?,memory,operating-system,Memory,Operating System,除去有效位、脏位和引用位,仅考虑从虚拟地址空间到物理地址空间的实际“映射”,为什么说页表项的大小由从主存引用页所需的位数决定(如此处:) 我的论点是,由于物理地址也可以在辅助存储器中(这是使用虚拟内存的要点),因此页表条目的大小应该简单地等于引用虚拟内存中所有页中的任何页所需的位数 举个例子,如果虚拟地址空间可寻址64位,主存可寻址48位,页面大小为16KB(可寻址14位),则页面表应将(64-14)50位地址映射到(64-14)50位地址,而不是(48-14)34位地址 如果页面存在于主存中,

除去有效位、脏位和引用位,仅考虑从虚拟地址空间到物理地址空间的实际“映射”,为什么说页表项的大小由从主存引用页所需的位数决定(如此处:)

我的论点是,由于物理地址也可以在辅助存储器中(这是使用虚拟内存的要点),因此页表条目的大小应该简单地等于引用虚拟内存中所有页中的任何页所需的位数

举个例子,如果虚拟地址空间可寻址64位,主存可寻址48位,页面大小为16KB(可寻址14位),则页面表应将(64-14)50位地址映射到(64-14)50位地址,而不是(48-14)34位地址

如果页面存在于主存中,则它可以映射到34位地址,否则,上限应为50位,这在计算页面表的大小时应予以考虑


我在这里遗漏了什么吗?

页表的大小必须考虑: 1.控制位 2.访问限制位 3.页面大小 4.访问所需页数所需的位数

页表条目对应于虚拟内存。条目数乘以页面大小即为虚拟地址大小


条目本身只需要寻址物理内存。

页表条目的大小可支持虚拟地址大小和支持的最大物理内存量。它们的大小不取决于辅助存储的任何方面

在您的示例中,页面表必须支持将
2^50
虚拟页面映射到可能的
2^34
物理页面。因此,页表条目将使用34位来保存物理页码


如果一个页面在内存中不存在,并且它以前被分页到辅助存储器,那么可以使用数据结构(如哈希表)来定位页面在分页文件中的位置。您不需要使用页表结构来实现这一点。

对,以我的示例为例,仅考虑引用页所需的位,页表中每个条目的大小是多少?我的50位上限正确吗?谢谢。那么,编写程序时是否假设它们将使用
2^64
字节(虚拟内存)或
2^48
字节(主内存大小)?在前一种情况下,我不理解为什么页表条目不应该映射到辅助存储(为什么要将其委托给单独的哈希表?)。在后一种情况下,当程序可能只能寻址
2^34
页面时,为什么页面表中应该有
2^50
条目。程序的编写假设它们使用2^64字节(假设编译器、操作系统和CPU都支持64位地址)。您希望保持PTE的大小较小,以便PTE缓存(TLB)可以较小。在PTE中输入足够的信息,以便您可以在backing store上找到页面,这可能会使PTE更大,而不会提高性能。@SachinHosmani-如果我的答案对您有效,请批准它。如果不满意,请告诉我为什么不满意。谢谢回复。你在回答中提到的哈希表到底叫什么?如果一个页面在内存中不存在,它的页面表条目是什么?显然,它不可能是一个内存位置。它必须指向这个哈希表。哈希表查找是如何进行的?页表条目将有
显示
/
有效
位关闭。PTE的所有其他部分无效。内核或交换进程需要能够将进程id和页码映射到备份存储中找到该页的位置。它可以位于包含流程代码的页面的常规文件中,也可以位于流程数据的交换文件中。这是您不想强制进入PTE的信息。