关于x64机器上的x86 LARGEADDRESSAWARE程序的c＃：内核模式内存大小？

Kernel Mode memory size for an x86 LARGEADDRESSAWARE program on an x64 machine?

标题几乎总结了一下。我有一个为x86平台编译的应用程序，该应用程序设置了/largeaddressaware标志。在x64系统上运行它，我可以"免费"获得扩展的4gb用户模式虚拟内存，而不必指定/3GB引导选项。在x86系统上，这意味着内核模式的内存仅为1gb，但是由于x64系统可以寻址更多的内存，因此内核模式是否保留2gb甚至提高到3gb？

编辑：明确地说，我想知道每个进程的限制。问题源于阅读本文。

编辑2：此问题不是在64位操作系统上32位进程可以访问多少内存的重复项？因为该问题仅解决了应用程序可访问的内存，而不是系统可访问的内存。如果我被误解了，并且每个进程都没有为系统保留内存，那么如果有人可以将其写成答案，我将不胜感激。我确定我不是第一个对此感到困惑的人。

 相关讨论

• 该标志在x64系统上不影响内核地址空间。我仍然为内核保留8TB(我认为)的地址空间。
• @MichaelBurr哇，我没想到。就是每个进程，对吧？
• 内核地址空间不是每个进程的。另外，请记住，即使地址空间被阻止，也不一定意味着有实际页面分配给了整个地址空间。
• 在x64系统上，用户模式进程获得4GB的地址空间，而不是3GB。内核以64位模式运行，因此它不需要使用任何32位地址空间。在最新版本的Windows上，内核地址空间为128TB。有关更多详细信息，请参见重复项的答案。
• (还请注意，询问每个进程的内核模式限制没有任何意义。内核不能那样工作。)
• @HarryJohnston我引用的文章(以及许多其他资源)将每个进程的内存描述为分为两个分区，一个分区可供应用程序访问(本文中的"用户模式"部分)，另一个为系统保留("内核模式")。"部分)。如果这是一个错误的陈述，并且每个进程都有其自己的"用户模式"部分，但"内核模式"在整个系统中共享，请在回答中写下该内容，因为我肯定不是第一个被混淆的人。
• 我想在关闭它时将其作为一个副本，我认为内核地址空间和用户地址空间是相互补充的，也就是说，如果您知道用户地址空间为3GB，则可以得出结论，内核地址空间必须为1GB。 。是的，但这显然不是事实。重病。

---

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

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

默认情况下，这是1：1拆分，因此您获得2 GiB的用户地址空间和2 GiB的内核地址空间。早期的32位Windows软件(当您的计算机可能只有486 CPU或类似的内存而只有4 MiB的内存)使用了(滥用)，因为由于内存的布局方式，您的用户地址空间永远不会有超过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位OS上的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位地址。

---

如您链接到的文章所述，32位CPU上可用的4GB地址空间分为两部分：用户模式或应用程序地址空间，以及内核模式地址空间。

用户模式地址空间是每个进程的。每个过程在用户模式地址空间中的页面与物理或虚拟内存之间都有不同的映射。

无论当前正在运行哪个进程，内核模式地址空间都是相同的。否则，每次转换到内核模式时都必须重新映射地址空间，这将非常低效。 (这篇文章的确如此，但只是非常简短："操作系统使它的虚拟内存在每个进程的地址空间中可见"。)

默认情况下，32位Windows将其平均划分，用户空间2GB，内核空间2GB，但可以配置为将其划分为3GB / 1GB。

在x64 Windows上，内核以64位模式运行，因此它可以访问CPU允许的全部地址空间，当前为48位或256TB。最初的x64 Windows版本仅使用16TB的地址空间，平均分配：8TB用于应用程序地址空间(对于64位应用程序)和8TB用于内核。在Windows 8.1中，将其增加为使用CPU允许的整个256TB，并再次平均分配：用于64位应用程序的128TB，用于内核的128TB。

32位应用程序在WOW64仿真环境中运行，而CPU在旧模式下运行。但是，内核永远不会在传统模式下运行。当需要内核转换时，必须将CPU从传统模式切换到长模式，这也意味着它从32位地址空间切换到64位地址空间。 x64 CPU的设计使这种转换非常有效。

结果，不需要为内核保留任何32位地址空间。

为了确保向后兼容，一个32位进程(其可执行文件未标记为支持大地址)仍限制为2GB地址空间。如果可执行文件支持大地址，则该进程将获得全部4GB。

您应该注意，这实际上是地址空间，而不是内存甚至虚拟内存。 32位应用程序可以使用文件映射和其他方法来使用超过4GB的内存。

您还应该注意，进程可以访问2GB / 3GB / 4GB的地址空间这一事实并不意味着应用程序可以使用所有这些空间。 Windows在每个进程中为其保留一些用户模式地址空间。

地址空间和其他限制在此处记录：Windows和Windows Server版本的内存限制。