为什么操作系统不能使用整个 64 位进行寻址？为什么只有 48 位？答案

【问题标题】：Why can't OS use entire 64-bits for addressing? Why only the 48-bits?为什么操作系统不能使用整个 64 位进行寻址？为什么只有 48 位？
【发布时间】：2011-03-14 06:29:34
【问题描述】：

我正在阅读“了解 Linux 内核”。

64 位架构的分页

正如我们在前面看到的部分，两级分页通常是由 32 位微处理器使用。然而，两级分页不是适用于采用 64 位架构。让我们使用一个思想实验来解释原因：

首先假设一个标准页面大小 4 KB。因为 1 KB 覆盖了一个范围 2¹⁰ 个地址，4 KB 涵盖 2¹² 地址，因此 Offset 字段为 12 位。这会留下多达 52 位的要分配的线性地址表和目录之间字段。 如果我们现在决定使用 64 位中只有 48 位用于寻址（这个限制给我们留下了一个舒适的 256 TB 地址空间！），剩下的 48-12 = 36 位将必须在 Table 和目录字段。如果我们现在决定为这两个中的每一个保留 18 位字段，页面目录和每个进程的页表应该包括 2¹⁸ 个条目，即超过 256,000 个条目。

“如果我们现在决定只使用 64 位中的 48 位进行寻址”。为什么？ & 为什么只有 48 位？为什么不是其他数字？
好吧，我只是一个普通的 PC 用户和程序员。我很难相信 32 位寻址，即每个进程 4GB（更正确的是 2GB/3GB）地址空间是一个限制。如果你真的遇到了这个限制。请举个例子。
windows 的这个限制是多少？
我知道虚拟内存！= 物理内存和处理器地址引脚与虚拟内存无关。这是一个完全不同的问题。如何知道处理器的地址引脚数量（= 地址总线的大小）。 http://ark.intel.com 处理器规格不包括此规格。

答案：

请参阅Paul Betts's answer 以获得第一个问题的合理答案。

【问题讨论】：

另见stackoverflow.com/questions/3196684/memory-addressing & stackoverflow.com/questions/132930/…

标签： windows memory-management 64-bit linux-kernel address-space

【解决方案1】：

这些答案都不是正确的，操作系统不使用完整的 64 位的原因是因为页表会大得多（64 位已经达到 3 级页表），并且没有支付额外间接所需的理由，48位就足够了。 48 位也很方便，因为您可以获得一些额外的位来存储标志（指针标记）

【讨论】：

你的回答也是错误的。 amd64 架构明确强制所有未使用的位为 1，以确保没有人存储带有地址的标志，并且页表可以只增加页大小。 1GB 的页面大小非常好，因为它们会开启虚拟分页并使程序运行速度非常快（您可以在 HP-UX 上进行测量）
@Lothar 你显然不能使用指针，而它有标志，但在 32 位中，你没有任何可以屏蔽的“已知”位在使用指针之前。

【解决方案2】：

“如果我们现在决定只使用 64 位中的 48 位进行寻址”。为什么？ & 为什么只有 48 位？为什么不是其他数字？

系统架构师做出权衡。 256TB 似乎足以容纳 1 个进程的地址空间。记住虚拟地址！=物理地址，一般来说，每个进程都有自己的地址空间。

只要指针是 64 位，这更多的是性能问题。如果 & 当 48 位成为限制时，可以调整操作系统以使用 64 位地址空间的更多位，而不会破坏应用程序的不兼容性。目前，建筑师们只是在为自己争取一段非常舒适的时间。

这可能与处理器端的虚拟寻址功能有关，因为现在许多处理器都有memory management units 来处理虚拟 -> 物理内存映射。

如何知道处理器的地址引脚数量（= 地址总线的大小）。 http://ark.intel.com 处理器规格不包括此规格。

这在很大程度上是无关紧要的。这是处理器实现各种物理寻址方案的一种方式。如果总线是同步的并且地址位及时多路复用，则 64 位处理器可以使用 64、32、16、8、4、2 或 1 个地址引脚为其完整的地址空间实现外部地址/数据总线。同样，虚拟地址！=物理地址； 64 位虚拟寻址可以用 48 位或 32 位物理地址实现（只是您将被限制为 2⁴⁸ 或 2³² 个字的内存）。

更新：如果您真的想知道，您必须查看每个相关处理器的数据表。例如。 Intel Core 2 Duo -- 数据表的第 4.2 节讨论了信号 -- 地址总线是 36 位宽（但实际上是 33 条信号线；数据宽度是 64 位 = 8 字节，所以其他 3 条线可能是不必要的正确的数据对齐）

好吧，我只是一个普通的 PC 用户和程序员。我很难相信 32 位寻址，即每个进程 4GB（更正确的是 2GB/3GB）地址空间是一个限制。如果你真的遇到了这个限制。请举个例子。

两个字：memory-mapped files。

【讨论】：

Remember virtual address != physical address。是啊，现在我也在梦里背诵它。 :P。是的，256TB 似乎很大，但现在似乎很大。一旦 1MB 被认为绰绰有余，32 位 IP 地址很快就会用完。当这个 256TB 将是一个限制。人们说，“现在是时候转向 64 位了”。该死！我讨厌它。
:-) 从程序员的角度来看，只要指针是 64 位就没有关系。
Jason：从重新编译的角度来看，当然。但这只是真的正确，只要程序员没有做出任何在 48 岁但在 64 岁时不正确的假设。:-) 任何人都会编写在 48 岁时工作的代码，但不是这样，这听起来很疯狂64，但是，我认为每个字长和字节序都发生了同样的变化。
@claws，这在家用 PC 上将是遥不可及的——如果有的话。 4GB 是 4096x 1MB，但 256TB 是 64,000x 4GB。我怀疑任何软件在 20 年内都需要/使用接近这么多 RAM —— 无论如何，还没有 iTunes。
Jason：这是一个好的问题！在过去的 20 多年中，当在 8 位、16 位、32 位和 64 位处理器（小端和大端）之间移植 C 代码时，我提出了完全相同的问题。我不知道为什么，但他们中的很多人肯定会这样做！

【解决方案3】：

当前的 x86-64 设计为此使用的数量不超过 48 bits - 所以这是一个方便选择的数字，而且它在 Windows 上也自动具有相同的限制。

【讨论】：

【解决方案4】：

我很难相信 32 位寻址，即每个进程 4GB（更准确地说是 2GB/3GB）地址空间是一个限制。如果你真的遇到了这个限制。请举个例子。

从 RAM 获取数据比从磁盘获取数据更有效（更快）。

SQL Server 的速度部分取决于它能够在 RAM 中而不是在磁盘上保存多少数据（例如，它的索引和数据页的数量）。

因此，SQL 数据库（例如）在 RAM 超过 4GB 的机器上可能会更快。

对于其他类型的服务器（例如文件服务器、HTTP 代理等）也是如此，如果它们可以有更大的 RAM 缓存，它们会更快。

【讨论】：

如果您需要更多内存。英特尔很久以前就提供了 PAE。它可以支持 64GB 的 RAM。这意味着将页面交换到磁盘的需要更少，所有 4GB 的页面都可以存在于主内存中。此外，在当前市场上，我认为 8GB 是主板可以支持的最大 RAM。移动 64 位是如何解决这个问题的？
@claws - 例如，Dell PowerEdge R910 支持高达 1 TB 的 RAM。
谢谢。我不知道有这样的野兽存在。 dell.com/us/en/enterprise/servers/rack_optimized/…
好吧，如今即使是普通的 100 美元主板也支持 16-24GB 的 RAM。
@claws - i7 桌面通常支持大约 24GB 的 DDR3。 8GB 限制（大部分）随着核心 2 线而消失。

【解决方案5】：

我认为最简单的答案是 - 摩尔定律。

摩尔定律基本上说 IC 每 18 个月成本减半。有一些方法可以解释这一点： PC 中安装的内存量往往每 18 个月翻一番。有效速度翻倍（至少如果您使用内核 * MHz 而不仅仅是 MHz）。

无论如何，我们真的用完了 32 位地址空间，所以从 32 到 48 的跳跃意味着，在硬件方面，我们已经为摩尔定律的大约 16 次迭代分配了扩展空间 - 大约 20年。

我很确定，虽然某些 PC 可能会被推到 10 年大关，但 20 年的扩展空间似乎是一个不错的权衡：20 年后的计算机将会有所不同 - 它们不会使用相同的 CPU 和RAM 总线，就像 20 年前不同。将超过 20 年的余量设计到一个界面中，对于永远不会被使用的工程设计简直是愚蠢的。

而且它不会太短以至于现有硬件存在过早淘汰的真正风险。

【讨论】：

【解决方案6】：

我很难相信 32 位寻址，即每个进程 4GB（更准确地说是 2GB/3GB）地址空间是一个限制。如果你真的遇到了这个限制。请举个例子。

它不再存在（除了在一些老员工的个人机器上），但我在 1990 年代末/2000 年代初开发了一套名为 RealiMation 的软件。这是一个用于可视化和模拟的实时 3D 引擎。我们的一位客户经常创建达到 2GB 内存限制的高度详细的模型。我们会在需要时动态加载纹理，并且必须添加代码来检查内存分配失败，以便我们可以继续显示模型，尽管没有纹理。

【讨论】：

【解决方案7】：

从硬件的角度来看，另一个考虑因素是对齐。

一旦您需要超过 4 个字节的数据类型，比如 6 个字节，您需要将它们放在 8 字节的边界上，以便在一条指令中检索它们。如果不对齐，则需要进行位屏蔽和移位，并在（汇编）代码中添加对此的检查。

许多人对切换到 64 位感到恼火，因为他们的程序消耗了如此多的内存。他们会想要 48 位指针，如果没有对齐限制，CPU 制造商可能会制作 48 位架构。

请注意，如果您非常需要内存以致希望指针为 6 个字节，那么有办法做到这一点。但是执行时间会受到惩罚。

【讨论】：