寻址超过 4 GB 的物理内存需要超过 Intel（32 位）处理器标准操作模式提供的 32 位地址。为此，Intel 从 Intel Pentium Pro 处理器开始引入了称为 PAE 的 36 位物理寻址模式。

本文介绍 Microsoft Windows 操作系统和多个 UNIX 操作系统用来为使用 PAE 模式寻址的应用程序提供支持的一些技术。因为在这些环境中运行的进程具有 32 位指针，所以操作系统必须以应用程序可以实际使用它的方式管理和呈现 PAE 的 36 位地址。关键问题是：操作系统是如何解决这个问题的？性能、功能、编程的简单性和这些问题处理方式的可靠性将决定大内存支持的实用性。

PAE：32 位与 64 位系统

PAE 仅在 32 位版本的 Windows 操作系统上受支持；64 位版本的 Windows 不支持 PAE。有关 64 位版本 Windows 的设备驱动程序和系统要求的信息，请参阅64 位系统设计。地址窗口扩展 (AWE) API 在 32 位系统上受支持。对于本机和 Wow64 应用程序，x64 系统也支持它。

虽然对 PAE 内存的支持通常与对 4 GB 以上 RAM 的支持相关联，但可以在 Windows XP SP2、Windows Server 2003 和更高版本的 Windows 32 位上启用 PAE 以支持硬件强制数据执行保护 (DEP) .

本文中的信息适用于 Windows 2000、Windows XP Professional、Windows Server 2003 以及这些操作系统的更高版本，在本文中简称为“Windows”。

技术背景

标准 32 位模式下的地址转换

所有 IA-32 处理器（Intel Pentium、Pentium Pro、Pentium II Xeon 和 Pentium III Xeon）都支持 32 位物理地址 (4 GB)，允许应用程序在运行时寻址 4 GB 的虚拟地址。系统必须将应用程序和操作系统使用的 32 位虚拟地址转换为硬件使用的 32 位物理地址。（Pentium Pro 是 IA-32 系列中第一个支持 PAE 的处理器，但通常缺乏 36 位物理地址也需要芯片组支持。）

Windows 使用两个级别的映射来进行转换，这由内存管理器创建和维护的称为页目录和页表的一组数据结构来促进。

PSE模式

IA-32 支持两种访问 4 GB（32 位）以上内存的方法。PSE（Page Size Extension）是第一种方法，随 Pentium II 一起提供。这种方法提供了兼容性优势，因为它保持了 4 字节的 PTE（页表条目）大小。然而，唯一实际的实现是通过驱动程序。由于读取和写入超过 4 GB 所需的缓冲区复制操作，此方法会受到严重的性能限制。PSE 模式用于 PSE 36 RAM 磁盘使用模型。

PSE 使用标准的 1K 目录并且没有页表来将页面大小扩展 4-MB（消除该模式的一级间接）。页目录条目 (PDE) 包含 14 位地址，当与 22 位字节索引结合时，会产生 36 位扩展物理地址。在 4 GB 以下同时支持 4 KB 和 4 MB 页面，标准方式支持 4 KB 页面。

请注意，位于 4 GB 以上的页面必须使用 PSE 模式（页面大小为 4 MB）。

PAE模式

PAE 是支持访问 4 GB 以上内存的第二种方法；这种方法已被广泛实施。PAE 使用 4 KB 或 2 MB 页面将最多 64 GB 的物理内存映射到 32 位 (4 GB) 虚拟地址空间。页目录和页表扩展为 8 字节格式，允许将页表和页框的基地址扩展为 24 位（从 20 位）。这是引入额外的四位来完成 36 位物理地址的地方。

Windows 支持具有 4-KB 页面的 PAE。PAE 还支持支持 2 MB 页面的模式。许多 UNIX 操作系统依赖于 2 MB 页面模式。地址转换是在不使用页表的情况下完成的（PDE 直接提供页框地址）。

操作系统实施和应用程序支持

下一个问题是操作系统如何管理和呈现 PAE 的 36 位地址，以便应用程序（具有 32 位指针）可以实际使用额外的内存。

有五种应用程序支持模型。前两个模型（服务器整合和大缓存）完全在操作系统中处理，不需要对应用程序进行任何更改。后两个模型（Application Windowing 和 Process Fork）需要更改应用程序以支持大内存的 API 扩展。最后一个模型（PSE 36 RAM 磁盘）不需要更改操作系统（在驱动程序中实现），但要求应用程序更改以支持驱动程序。

1. 服务器合并

支持 PAE 的操作系统应该能够利用系统提供的所有物理内存来加载多个应用程序；例如，App#1、App#2、App #N，每个都包含 4 GB（最大）的虚拟地址。在未启用 PAE 的系统中，结果可能是大量分页，因为系统中的最大物理内存被限制为 4 GB。

借助 PAE 模式下支持的额外物理内存，操作系统可以在内存中保留更多此类应用程序而无需分页。这在支持服务器整合配置方面很有价值，其中通常需要在单个服务器中支持多个应用程序。请注意，无需更改应用程序即可支持此功能。

2. 大缓存

也可以使用额外的支持 PAE 的内存作为数据缓存。如果操作系统支持此功能，则应用程序无需重新编码即可利用它。Windows Advanced Server 和 Datacenter Server 支持 PAE 平台上的缓存，并且可以利用所有可用内存。

3. 应用窗口

支持 PAE 的操作系统可以引入 API 以允许正确编码的应用程序访问系统中任何位置的物理内存，即使它可能超过 4 GB。理想情况下，用于分配“高”物理内存和创建或移动窗口的 API 应该快速且易于编写代码。这对于需要快速访问内存中大量数据的应用程序非常有利。

在进程之间共享高端内存会给 API 和实现带来相当大的复杂性。Windows 避免这种共享。

此外，分页的支持使得操作系统的设计和实现难度大增，确定性性能更难实现。Windows 也避免了高端内存的分页。

4. 进程fork和共享内存

此应用程序支持模型将当前进程拆分为两个或多个几乎相同的副本。副本由用户和系统堆栈、分配的数据空间和寄存器组成。主要区别在于一个具有父进程的进程 ID (PID)；另一个具有父进程的进程 ID (PID)。另一个有一个新的 PID。fork 返回一个 PID 值。子副本的 PID 为零，父副本的子副本的 PID 为零。

5. PSE36内存盘

通过使用内核设备驱动程序，就像 RAM 磁盘一样，可以在不对操作系统进行任何更改的情况下使用 4 GB 以上的内存。基本操作系统（以 32 位模式运行）和驱动程序（以 PAE 模式运行）之间的兼容性得以保持，因为页表保持在 4 字节宽。这种非常低的发展影响的权衡有几个：

• 由于强制所有 I/O 执行双缓冲，性能下降。
• 应用程序开发影响并不明显小于当前 API 所需的影响。
• 它不能用作“整合服务器”，因为所有应用程序共享相同的 4 GB 物理内存空间。

设计实施

大内存支持的操作系统实现必须直接解决这些问题才能成功。根据在处理这些问题时所做的设计选择，操作系统的简单性、可靠性和性能将受到直接影响。

IA32 中大内存支持的技术问题

内存共享和进程间通信

在内存重映射被用于为进程分配内存的所有情况下，这对许多 PAE 变体都很常见，内存共享是有问题的。被重新映射的物理内存在进程虚拟地址空间的“外部”。因此，就共享进程的内部访问和安全控制以及操作系统提供的那些而言，物理内存与进程的连接较少。

要应用访问和安全控制，有必要大大增加操作系统内存管理器所需的簿记以及应用程序开发人员必须使用的 API 集。这会对使用非常快速的重映射操作可能实现的高性能产生负面影响。同样重要的是要记住，在任何情况下，IPC/内存共享仍可能发生在两个进程的虚拟地址空间之间，而不管每个进程可能使用的物理映射内存如何。

TLB击落

翻译后备缓冲器 (TLB) 是处理器寄存器或高速缓存，它提供页表条目的直接逻辑到物理映射。加载后，处理器必须很少读取页目录（TLB 未命中），除非发生任务切换。

在重新映射操作期间，有必要确保所有处理器在芯片上具有有效的逻辑到物理映射。因此，重新映射操作需要 TLB 击落，因为逻辑到物理的关联因重新映射而无效（其中“逻辑”= 内存的应用程序/进程视图）。

当处理器（或多个处理器）重新加载 TLB 时，性能会受到影响。所有操作系统都有这个问题，在 PAE 内存支持的情况下，它们以不同的方式改善这个问题：

• Windows 为单个应用程序提供了“批处理”所需的重新映射操作的能力，以便所有操作同时发生，并且只会导致一次 TLB 击落和一次性能下降，而不是随机重新映射，每一种都会影响性能。这对于通常在单一用途系统上运行的大型应用程序来说已经足够了。

• 其他操作系统提供“受害者”缓冲区或允许一个进程共享另一个进程的映射，但代价是更多的同步和 API 复杂性。

  Windows XP 还提供了这种“批处理”或分散/聚集功能。此外，这些操作的性能已针对 Windows Server 2003、Enterprise Edition 和 Datacenter Edition 进行了改进。

输入/输出

在一个级别或另一个级别，所有 PAE 变体都支持 32 位和 64 位 DMA I/O 设备以及附带的驱动程序。但是，有一些附带条件和条件。

内核和内存组织

通常，内核内存空间组织与操作系统的标准内核没有变化。在许多情况下，内存池大小等项目保持不变。为了向后兼容，PCI 基地址寄存器 (BAR) 保持不变。较大的内存大小会导致内核地址空间发生一些偏移，通常是在系统中物理内存在 16 GB 到 32 GB 之间时。

操作系统之间的一个区别是内存分配是否是动态的：

• 某些操作系统要求管理员配置用于各种用途（缓存、映射、整合等）的内存量。
• Windows 不需要管理员配置内存分配，因为使用是动态的，在所用 API 的约束范围内。

硬件支持

PCI 标准提供了一种方法，通过这种方法，适配器可以通过在两个单独的发送中发送高 32 位地址和低 32 位地址来物理寻址超过 4 GB 的内存。这称为双地址循环 (DAC)，既用于理解 64 位地址但只有 32 条地址线的 32 位适配器，也用于具有 64 条地址线的适配器。这是一个向后兼容的特性。

鉴于 PCI 寻址超过 32 位内存的方法，存在一种微妙的故障模式。必须对“跨越”两个 4 GB 区域的任何 I/O 范围进行特殊处理。否则，地址范围将仅针对传输的一部分被正确解码，而其余部分将被转移到不正确的内存位置。这会损坏内存并导致系统崩溃、应用程序崩溃或在该位置默默地损坏数据。应用程序无法阻止这种情况，因为它们仅显示虚拟地址并且对物理级别没有可见性。所有使用 PAE 的操作系统都面临这个问题，但有些操作系统并没有明确阻止这种情况的发生，而是依赖于设备驱动程序来采取正确的操作。

然而，Windows 明确地阻止了这个问题。当 I/O 范围以这种方式跨越时，Windows 将两个单独的地址和范围返回给设备和驱动程序。最后一个特例是从 4 GB 到 4 GB 的第一个过渡。4 GB 以下的区域不需要 DAC，但传输的其余部分需要 DAC。同样，在这种情况下，Windows 会返回两个独立的地址和范围，以防止内存损坏。

显然，DAC 或 64 位适配器和驱动程序可提供最佳性能，因为不会发生 I/O 缓冲。但是，只要适配器和驱动程序不能使用超过 32 位的地址信息，就需要这种缓冲。所有使用 PAE 模式寻址的操作系统都以某种方式支持这种“双缓冲”，作为向后兼容功能。这种缓冲确实有性能损失，这取决于几个因素：

• 适配器硬件性能
• 司机表现
• 为双缓冲提供操作系统支持
• 系统中安装的物理内存量

随着物理内存的增加，超过 32 位的 I/O 地址的相对数量也相对于低于 32 位的地址增加。在大多数情况下，操作系统透明地提供双缓冲，尽管一些 Unix 变体不提供此功能的任何帮助并且需要任何 32 位设备和驱动程序来管理它们自己的双缓冲例程和分配。

驱动程序问题

通常，设备驱动程序必须以许多小的方式进行修改。尽管实际的代码更改可能很小，但它们可能很困难。这是因为当不使用 PAE 内存寻址时，设备驱动程序可能会假定物理地址和 32 位虚拟地址限制是相同的。PAE 内存使这个假设不正确。

以前可以安全使用的几个假设和捷径不适用。一般来说，这些分为三类：

• 必须修改分配和对齐共享内存缓冲区的代码中的缓冲区对齐，以便它不会忽略物理地址的高 32 位。
• 必须避免在可能保留的许多位置截断地址信息。
• 有必要严格隔离虚拟和物理地址引用，以便 DMA 操作不会将信息传输到随机内存位置或从随机内存位置传输信息。

可以在 Windows XP SP2、Windows Server 2003 SP1 和更高版本的 Windows 上启用 PAE 模式以支持硬件强制 DEP。但是，许多为这些系统设计的设备驱动程序可能尚未在启用 PAE 的系统配置上进行测试。为了限制对设备驱动程序兼容性的影响，对 Windows XP SP2 和 Windows Server 2003 SP1 标准版的硬件抽象层 (HAL) 进行了更改，以将物理地址空间限制为 4 GB。鼓励驱动程序开发人员阅读有关DEP的内容。

分页

大多数支持 PAE 的操作系统都支持超过 4 GB 的物理内存的某种性质的虚拟内存分页。这通常发生在一些限制条件下，例如将引导/系统页面文件限制为 4 GB 或将页面文件（或多个文件）分布在多个操作系统组织的卷（不一定是物理轴）上。

虽然这允许虚拟内存的明显好处，但缺点是对具有以下一个或多个特征的应用程序的性能影响：

• 为他们的数据集使用大量的物理内存
• 做大量的 I/O
• 拥有大型可执行工作集

最后，分页支持通常是以增加 API 集和减慢开发和版本迁移为代价的。

用户 API

所有支持 PAE 的操作系统都有 API，允许进程使用超出 IA-32 处理器上可能的虚拟地址范围的物理内存。它们的主要区别在于它们为前面描述的项目提供了多少支持：内存共享、进程间通信、分页等。Windows 提供了一个简单直接的 API 集——Address Windowing Extensions (AWE) API 集——它只包含五个 API 调用，最复杂的 API 大四倍，涉及内核和用户级调用。

专有 API 的激增——其中一些直接绑定到处理器架构（内核级）——使得将应用程序从一个 Unix 变体移植到另一个变体变得昂贵、耗时，并且需要不断努力平衡成本与性能优化。Windows 提供了一个 API 集，它在 32 位和 64 位硬件平台之间简单、快速且完全可移植，只需重新编译即可运行。

页面大小

在为应用程序提供超过 4 GB 的物理内存时，几乎所有支持 PAE 的操作系统都使用不同的页面大小。主要的例外是 Windows，它在 IA-32 平台上仅向应用程序提供 4 KB 页面（这在基于 Itanium 的平台上有所不同）。

为应用程序使用不同页面大小的问题与使用不同内存分配大小正确运行所需的额外应用程序复杂性有关，以及与几乎所有应用程序对页面大小的基本假设相关的微妙影响。尽管研究表明一小部分应用程序可以从更大的页面大小（2 MB 或 4 MB）中受益，但由于每个 TLB 条目跨越更大的地址范围，一般规则是应用程序不会从更大的页面大小中受益。

Windows 和 PAE

有关 PAE 和 Windows 的更多信息，包括开发人员指南，请参阅PAE 内存和 Windows。

（本文直接采用机翻转译，原网页：操作系统和 PAE 支持 - Windows 10 硬件开发|微软学习 (microsoft.com)）