c# - x64 机器上 x86 LARGEADDRESSAWARE 程序的内核模式内存大小？

Question

标题几乎概括了它。我有一个为 x86 平台编译的应用程序，它设置了 /largeaddressaware 标志。在 x64 系统上运行它，我“免费”获得了扩展的 4GB 用户模式虚拟内存，而无需指定 /3GB 启动选项。在 x86 系统上，这意味着内核模式内存仅为 1GB，但由于 x64 系统可以寻址更多内存，内核模式是否会保留 2GB 甚至增加到 3GB？

编辑:明确地说，我想知道每个进程的限制。问题源于阅读 this article .

编辑 2:这个问题不是 How much memory can a 32 bit process access on a 64 bit operating system? 的重复问题因为该问题仅涉及应用程序可访问的内存，而不是系统可访问的内存。如果我误解了并且没有为每个进程的系统保留内存，那么如果有人可以将其写下来作为答案，我将不胜感激。我敢肯定我不是第一个对此感到困惑的人。

Answer 1

有一些误解让您感到困惑。

首先，让我们看一下 32 位 Windows。每个进程的虚拟地址空间都有一部分分配给进程本身，还有一部分用于内核需要的任何内容。但是，所有进程都共享相同的内核内存——事实上，您甚至在自己的虚拟地址空间中拥有内核内存，这基本上是一种性能优化，可以避免在处理应用程序中的内核对象和数据时切换地址空间。

默认情况下，这是 1:1 拆分，因此您将获得 2 GiB 的用户地址空间和 2 GiB 的内核地址空间。这被早期的 32 位 Windows 软件(当您的计算机可能只有 4 MiB 的内存和 486 CPU 或类似的)使用(滥用)，因为由于内存的布局方式，您的用户地址空间从来没有任何指针 高于 2 GiB 障碍 - 有效地为您提供任何指针的最高位，供您自己的数据免费使用。通常这被用来允许混合“如果它适合，这是一个值，否则它是一个指向结构的指针”方法，节省内存和一些间接。由于这是如此广泛，默认情况下与早期的拆分相同，以防止出现兼容性问题。但是，您也可以选择加入不同的拆分 - 3 GiB 的用户空间和 1 GiB 的内核空间。这就是 /3GB 选项的作用。但这还不够——您的应用程序必须还使用 /LARGEADDRESSAWARE 选择加入。这基本上是在说“我不会用我的指针做奇怪的事情”。

应该注意的是，32 位操作系统或进程并不一定意味着您只能寻址 4 GiB 的内存 - 它只是限制了 CPU 在任何时候可以直接访问的内容。对于内存密集型服务器软件，即使是“32 位”版本也可能支持寻址更多的内存——例如，32 位 MS SQL Server 通过 AWE 支持高达 64 GiB。这基本上是另一层虚拟化，它允许重新映射虚拟地址的物理地址。理论上，无论有无 AWE，您可以寻址的内存量都没有限制 - 毕竟，没有什么能阻止您拥有自己的硬件作为内存映射文件，有效地为您提供无限的地址空间。当然，就像分段内存的时代一样，它不是很容易使用或实用:)

在 64 位 Windows 上，/3GB 不再有任何意义并被忽略。默认地址空间拆分取决于 Windows 的确切版本，但在“TB 或更多”范围内，超出了 32 位限制。对于现代 Windows，这通常是 128 TiB 用户 + 128 TiB 内核。 32 位应用程序仍然必须像以前一样使用 /LARGEADDRESSAWARE。但是，由于内核现在是 64 位的，无论如何它都不能与用户进程位于同一地址空间中，因此 64 位操作系统上的 32 位应用程序可以完全访问 4 GiB 地址空间。

当然，这些限制仍然远低于 64 位理论上能够解决的问题。然而，大多数 64 位 CPU 实际上不能寻址整个 64 位地址空间——我上次检查时最常见的只是 48 位。令人惊讶的是，这为您提供了 256 TiB 的地址空间，这是 Windows 中的限制。毕竟不是微软的阴谋! :) 实际上，这并不是什么新鲜事。 Intel x86 的 32 位 ALU 与 32 位地址空间相关联的事实在 CPU 历史上是一个非常离群的事实 - CPU 通常具有比其 ALU 宽度更高或更低的地址空间(用于虚拟寻址或物理寻址)宽度. MS DOS 1 MiB 可寻址内存的典型限制(640 kiB 留给用户应用程序)也来自于此 - 当时的“32 位”CPU 只能使用 20 位地址。