为什么 4 级分页只能覆盖 64 TiB 的物理地址
Why 4-level paging can only cover 64 TiB of physical address
linux/Documentation/x86/x86_64/5level-paging.rst
中有词
Original x86-64 was limited by 4-level paging to 256 TiB of virtual address space and 64 TiB of physical address space.
我知道虚拟地址的限制是256TB 因为2^48 = 256TB。但是我不知道为什么它的物理限制只有64TB。
假设我们将每页的大小设置为4k。因此一个线性地址有12位偏移量，9位表示每四层的索引，即每层512个表项。线性地址可以覆盖 512^4 页，512^4 * 4k = 256TB 页，共 space 页。
这是我对space极限计算的理解。我想知道它有什么问题。
x86-64 ISA 的物理地址 space 限制在 PML5 中没有改变，仍然是 52 位。真正的 CPUs 实现了一些更窄的物理地址位，在缓存标签和 TLB 条目等地方节省了位。
64 TiB 限制不是由 x86-64 本身强加的，但顺便说一下，Linux 需要比物理地址更多的虚拟地址 space 以方便和高效。请参阅 x86_64/mm.txt 了解 Linux 的虚拟地址 space 在 x86-64 上的 PML4 分页的实际布局，并注意 64 TB“direct所有物理内存的映射(page_offset_base)"
x86-64 Linux 不执行 HIGHMEM / LOWMEM
Linux 实际上不能使用超过 phys mem = 1/4 虚拟地址 space，没有像在 RAM 超过 1 GiB (vm/highmem.html) 的机器上使用 32 位内核的糟糕日子。 （使用 3:1 user:kernel 地址拆分 space，让 user-space 有 3GiB，但内核必须映射页面 in/out 自己的 space 如果不是通过当前进程的 user-space 地址访问它们。）
Linus's rant about 32-bit PAE 扩展了为什么 OS 有足够的虚拟地址 space 来保持所有映射是好的，通常断言不同意他的人是白痴。 :P 我倾向于同意他的观点，有明显的效率优势，而且 PAE 对于内核来说是一个巨大的 PITA。在 SMP 系统上可能更是如此。
如果有人提出了一个补丁来添加对 x86-64 的 highmem 支持，以允许使用超过 64 TiB 的物理内存和现有的 PML4 格式，我希望 Linus 会告诉他们 1995 调用并想要它的坏主意背部。他不会考虑合并这样的补丁，除非服务器的 RAM 变得很普遍，但硬件供应商仍然没有提供更宽虚拟地址的扩展。
幸运的是，这并没有发生：可能没有 CPU 在不支持 PML5 的情况下支持比 46 位更宽的物理地址。供应商知道支持比主线 Linux 可以使用更多的 RAM 不是卖点。但正如文档所说，商业系统的最大容量可达 64 TiB。
x86-64 的 page-table 格式有 52 位物理地址的空间
x86-64 page-table 格式本身一直有那么多空间： 有来自 AMD 手册的图表。当然，早期的 CPUs 具有较窄的物理地址，因此您不能让 PCIe 设备将其设备内存放在物理地址 space.
的高位
您的计算与物理地址限制无关，物理地址限制由每个 page-table 条目中可用于此的位数设置。
在 x86-64（和 PAE）中，页面 table 格式保留位直到位 #51 用作 physical-address 位，因此 OSes 必须将它们归零与未来 CPU 的向前兼容性。低12位用于其他用途，但物理地址是通过将PTE中除phys-address位以外的位置零而形成的，因此那些低12位成为对齐的[=68中的低零位=] 地址.
x86 术语说明：逻辑地址是 seg:off，segment_base + 偏移量为您提供线性地址。启用分页后（在长模式中需要），线性地址是虚拟的，并且用作页面 tables 的搜索关键字（实际上是 TLB 缓存的基数树）。
您的计算正确地重申了虚拟地址 space 的 256 TiB 大小，基于具有 4k 页的 4 级页 tables。那就是用PML4可以同时映射多少内存。
物理页面必须与虚拟页面大小相同，在 x86-64 中是 4 KiB。 （或 2M largepage 或 1G hugepage）。
有趣的事实：x86-64 page-table-entry 格式与 PAE 相同，因此现代 CPUs 也可以访问大量内存 32 位模式。但当然不能一次全部映射。 AMD 在制作 AMD64 时选择使用现有的 well-designed 格式可能不是巧合，因此他们的 CPU 只需要两种不同的硬件模式 page-table walker：legacy x86 with 4-字节 PTE（每级 10 位）和 PAE/AMD64 8 字节 PTE（每级 9 位）。
linux/Documentation/x86/x86_64/5level-paging.rst
中有词Original x86-64 was limited by 4-level paging to 256 TiB of virtual address space and 64 TiB of physical address space.
我知道虚拟地址的限制是256TB 因为2^48 = 256TB。但是我不知道为什么它的物理限制只有64TB。
假设我们将每页的大小设置为4k。因此一个线性地址有12位偏移量，9位表示每四层的索引，即每层512个表项。线性地址可以覆盖 512^4 页，512^4 * 4k = 256TB 页，共 space 页。
这是我对space极限计算的理解。我想知道它有什么问题。
x86-64 ISA 的物理地址 space 限制在 PML5 中没有改变，仍然是 52 位。真正的 CPUs 实现了一些更窄的物理地址位，在缓存标签和 TLB 条目等地方节省了位。
64 TiB 限制不是由 x86-64 本身强加的，但顺便说一下，Linux 需要比物理地址更多的虚拟地址 space 以方便和高效。请参阅 x86_64/mm.txt 了解 Linux 的虚拟地址 space 在 x86-64 上的 PML4 分页的实际布局，并注意 64 TB“direct所有物理内存的映射(page_offset_base)"
x86-64 Linux 不执行 HIGHMEM / LOWMEM
Linux 实际上不能使用超过 phys mem = 1/4 虚拟地址 space，没有像在 RAM 超过 1 GiB (vm/highmem.html) 的机器上使用 32 位内核的糟糕日子。 （使用 3:1 user:kernel 地址拆分 space，让 user-space 有 3GiB，但内核必须映射页面 in/out 自己的 space 如果不是通过当前进程的 user-space 地址访问它们。）
Linus's rant about 32-bit PAE 扩展了为什么 OS 有足够的虚拟地址 space 来保持所有映射是好的，通常断言不同意他的人是白痴。 :P 我倾向于同意他的观点，有明显的效率优势，而且 PAE 对于内核来说是一个巨大的 PITA。在 SMP 系统上可能更是如此。
如果有人提出了一个补丁来添加对 x86-64 的 highmem 支持，以允许使用超过 64 TiB 的物理内存和现有的 PML4 格式，我希望 Linus 会告诉他们 1995 调用并想要它的坏主意背部。他不会考虑合并这样的补丁，除非服务器的 RAM 变得很普遍，但硬件供应商仍然没有提供更宽虚拟地址的扩展。
幸运的是，这并没有发生：可能没有 CPU 在不支持 PML5 的情况下支持比 46 位更宽的物理地址。供应商知道支持比主线 Linux 可以使用更多的 RAM 不是卖点。但正如文档所说，商业系统的最大容量可达 64 TiB。
x86-64 的 page-table 格式有 52 位物理地址的空间
x86-64 page-table 格式本身一直有那么多空间：
您的计算与物理地址限制无关，物理地址限制由每个 page-table 条目中可用于此的位数设置。
在 x86-64（和 PAE）中，页面 table 格式保留位直到位 #51 用作 physical-address 位，因此 OSes 必须将它们归零与未来 CPU 的向前兼容性。低12位用于其他用途，但物理地址是通过将PTE中除phys-address位以外的位置零而形成的，因此那些低12位成为对齐的[=68中的低零位=] 地址.
x86 术语说明：逻辑地址是 seg:off，segment_base + 偏移量为您提供线性地址。启用分页后（在长模式中需要），线性地址是虚拟的，并且用作页面 tables 的搜索关键字（实际上是 TLB 缓存的基数树）。
您的计算正确地重申了虚拟地址 space 的 256 TiB 大小，基于具有 4k 页的 4 级页 tables。那就是用PML4可以同时映射多少内存。
物理页面必须与虚拟页面大小相同，在 x86-64 中是 4 KiB。 （或 2M largepage 或 1G hugepage）。
有趣的事实：x86-64 page-table-entry 格式与 PAE 相同，因此现代 CPUs 也可以访问大量内存 32 位模式。但当然不能一次全部映射。 AMD 在制作 AMD64 时选择使用现有的 well-designed 格式可能不是巧合，因此他们的 CPU 只需要两种不同的硬件模式 page-table walker：legacy x86 with 4-字节 PTE（每级 10 位）和 PAE/AMD64 8 字节 PTE（每级 9 位）。