32 位物理页表分辨率答案

【问题标题】：32-bit physical page table resolution32 位物理页表分辨率
【发布时间】：2011-10-11 07:18:41
【问题描述】：

我在支持 64 位（即 x86-64）的架构上以传统模式运行 32 位系统。当创建一个新进程时，内核必须决定在物理内存中的哪个位置分配实例化时所需的所有页面（假设一个线程，这可能包括多个内存区域，例如堆栈、堆等） .

我假设内核保留了某种正在使用的物理 RAM 帧的动态列表，以及已被使用内存的系统的设备占用的所有物理内存区域的静态列表-映射 IO。这是正确的吗？

此外，我还读到 32 位 Windows 系统的物理内存限制为 4GB（可能是由于最小地址总线假设），因此，即使系统可能安装了超过 4 GB 的物理内存，a 32 位内核只会分配 4GB 范围内的地址。

在网上很难找到有关针对特定情况的低级操作系统实现的具体信息。任何人都可以验证这些陈述并可能将我推荐给我可以获得更多信息的来源吗？

感谢您的考虑。

【问题讨论】：

一次只问一个问题。
@Hans：这两个子问题都与内核虚拟内存管理/分配的底层问题有关

标签： windows memory x86 kernel

【解决方案1】：

当一个新进程被创建时，内核必须决定在物理内存中分配实例化时所需的所有页面

为什么必须在进程创建时决定？事实上，它只是按需创建它们 - 它只是创建 PTE（即“此地址范围有效”，但页面不以任何方式支持）；当进程第一次开始执行时，它会立即page-faults。

什么是页面错误？发生的情况是，首先 CPU 读取 TLB 以查看它是否具有地址帧映射。当失败时，它会遍历 PTE 寻找匹配的条目。如果没有找到条目，或者如果该条目表明该页面没有被支持，则生成一个 page-fault。这意味着，发生 CPU 异常并且 CPU 立即跳转到预定义的地址。内核做的第一件事是保存 CPU 上下文（即错误位置的寄存器），然后分派给页面错误处理程序。

当页面错误发生时，Mm（NT 中的内存管理器）会读取它自己的数据结构中的映射（记住所有的 PE 映像都是内存映射文件），并在那时确定哪个物理帧（即'一块真正的内存'）将被使用。

一旦页面错误得到处理，页面错误就会恢复保存的 CPU 上下文，并跳回到原来的位置，并重试出错的指令。

你说得对，32 位操作系统只会使用 4GB 的地址空间（不是 RAM！不要忘记那些内存映射的设备和文件！），处理器将在32 位模式并将 PTE 解释为 32 位（请记住，AMD64 长模式添加了额外级别的页表并将地址空间扩展到 48 位）。

【讨论】：

非常感谢您的洞察力。在第二段中，您说“如果没有找到条目......”这是否意味着页表被实现为链表（或某种类型的非静态数据结构）？还是它们只是固定大小（1024 个条目）的数组？
我知道这是虚拟地址空间的指令内存区域的进程，因为虚拟内存中的进程映像直接映射到磁盘空间。因此，在尝试访问辅助存储时会产生页面错误。但是，我仍然不相信对于没有“预映射”到任何有效位置（既不在 RAM 也不在磁盘上）的其他内存区域（例如堆/堆栈页面），情况就是如此。您是说这些页面在访问时被分配/分页到物理内存上？
它们被实现为具有指向其他结构的指针的结构，它本身不是链表，但也不是单个连续块
我保证，这就是它的工作原理！如果您分配 1GB 的内存，则实际上其中的零实际上被保留为物理帧。当您页面错误时，该虚拟地址被分配了一个物理帧
感谢您的澄清。作为后续问题，内存管理单元如何区分没有保留在物理内存中的虚拟页和无效页（不在进程地址空间内的虚拟页）？无效页面是您在第二段中提到的“未找到条目”的虚拟页面吗？

【解决方案2】：

32 位系统只能直接寻址 4gig (2^32 = 4gig)。有PAE hack，它让系统拥有超过 4gig 的物理内存，但没有进程可以拥有超过 4gig 的可用内存。同样，即使您有 4gig 的 ram，您也永远不会看到超过 3.5gig 左右的实际可用内存 - 有些是为内存映射硬件设备保留的，例如您的视频 ram。

有关处理物理-虚拟内存映射的一种方法，请查看TLB

【讨论】：

感谢您的回复。我的问题不是关于分页机制实际上是如何工作的，而是它是如何建立和管理的。 TLB 只是一个包含 PTE 的缓存，用于加速虚拟地址转换过程。也许我在您链接的维基百科 TLB 页面上遗漏了一些东西，但我认为它没有说明系统内核如何管理页表/目录的分配。