关于大内存（大于4G）支持的问题

　　问题

　　Windows中4G大内存支持的问题

　　解决方案

　　本文是根据微软相关英文页面翻译后和其它资料整合而来。

　　http://support.microsoft.com/kb/283037/zh

　　http://support.microsoft.com/kb/283037/en

　　因为4G以上的物理内存已经超过了现在Intel(32-bit)处理器所能够提供的32bit寻址范围,所以Intel从Pemtium Pro处理器开始提供了这种被称为"PAE"的36位寻址方式;

　　本篇文章介绍了一些Windows操作系统以及许多UNIX操作系统所用来支持PAE寻址的技术.因为运行在这些环境上的处理器使用的是32位的指针,所以必须由操作系统来管理并且提供程序可用的36位PAE寻址方式.问题的关键点在于:操作系统如何来解决这个问题?效能,功能性,程序设计的建议性,以及处理方法的可靠性将直接决定大内存支持的实用性;

　　PAE只能在32位的windows系统上使用;64位的windows系统不支持PAE;如果需要查找关于64位windows对设备驱动和系统的要求信息,可以查看<<64-bit System Design>>(http://www.microsoft.com/whdc/system/platform/64bit/default.mspx).32位系统上现在已经支持地址窗口扩展 (Address Windowing Extension,AWE) 的API集了,同时对本地和Windows-on-Windows 64 (WOW64)模式下的应用程序,x64 systems页支持这个API集

　　虽然对于PAE的支持一般是和管理大于4G以上的内存联系在一起的,但是它也在windows xp sp2,windows server2003和随后的32位系统自动启用,用来支持硬件强制的数据执行防护功能(Data Execution Prevention ,DEP)http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx;

　　本篇文章针对windows 2000, xp professionnal,server 2003,以及随后的操作系统版本,下面通称windows;

　　技术背景:

　　标准的32位寻址方式

　　所有的IA-32处理器(Intel Pentium、Pentium Pro、Pentium II Xeon 與 Pentium III Xeon)都支持32位的物理地址(4GB),允许应用程序在执行时配置4GB的虚地址.系统必须将应用程序集操作系统使用的32位虚地址转化为硬件使用的32位的物理地址.(Pentium Pro是IA -32系列中第一种支持PAE的处理器,不过它的36位物理地址需要芯片组支持,这通常是不能满足的)

　　在一组由内存管理器产生的分页目录和分页表的作用下,windows使用两级映射来完成这种转换

　　PSE 模式

　　IA-32支持两种访问超过4GB(32位)的内存的方法;PSE(Page Size Extension,分页大小扩展)是第一种方法,已经在Pentium II上实现了.这种方法的有点是兼容性好,因为它保留了4byte大小的PTE(page table entry,分页表条目).然而,这种方法只能通过驱动程序实现.这样就受到了较大的性能限制,因为在读写超过4GB的内存时,一个缓存区复制的操作是必须的.PSE模式在PSE 36 RAM磁盘使用模式中使用.

　　PSE不使用任何的分页表而使用标准的1k目录将页面表延伸至4MB的大小(为该模式消除了间接的一层).分页条目(PDE)包含14位的地址,并且结合了22 位的索引,从而产生了36位的扩展物理地址,低于4GB的时候同时支持4KB和4MB的页,标准情况下支持4KB页.

　　注意:高于4GB的分页必须使用PSE模式(4MB分页大小)

　　PAE模式

　　PAE是第二种支持4GB以上内存大小的方法;这种方法已经被广泛地使用.PAE以4KB或者2MB的分页将最多64GB的物理内存映射到32位(4GB)的虚地址空间.分页目录及分页表被扩展到8 byte的格式,这样就允许分页表和分页框架的基础地址延伸至24位(原来是20位).这样,额外的4 bit就被用来构成了36位的物理地址.

　　windows以4KB分页大小支持PAE.PAE也支持2MB分页大小的模式.许多UNIX系统采用2MB分页模式.地址转换不需要使用到分页表(PDE直接提供页面框架地址);

　　操作系统运作和应用程序支持

　　下一个主题是操作系统如何管理和提供PAE的36位地址,使应用程序(才用32位指针)能够确实地使用额外的内存空间.

　　共有5种应用程序支持的模式,前两种(服务器整合'Server Consolidation'和大Cache)是完全在操作系统中实现的,不需要对程序做出任何修改.接下来的两种模式(应用程序窗口Application Windowing 和进程分支Process Fork)必须将应用程序改为支持大内存API扩展.最后一个模式(PSE 36 RAM磁盘)不需要做操作系统作出任何改变(在驱动中实行了),但是要求改变应用程序以支持驱动.

　　1.服务器整合

　　启用PAE的操作系统需要能利用系统提供的所有的物理内存来载入多个应用程序;例如App#1、App#2、App #N,每个包括4GB(最大)的虚地址.在一个没有启动PAE的系统中,结果会是大量的分页,因为系统最大的物理地址被限制在4GB.

　　使用PAE模式下新添加的额外物理地址,一个操作系统能够在不分页的情况下在内存中驻存更多的应用程序.这在支持服务器整合的配置上是相当有价值的,因为这种配置需要在单一服务器上支持多重应用程序.注意:需要支持本功能并不需要对应用程序进行任何修改

　　2. 大cache

　　对数据高速缓存使用额外的PAE内存也是可行的.如果操作系统支持这个属性,应用程序使用本功能时不需要被记录.windows advanced server和datacenter server支持在一个PAE平台上快速存取,而且能使用所有可用的内存

　　3. 应用程序窗口

　　一个启用PAE的操作系统能采用API来允许一个正确编码的应用程序无论在系统中的何处都能访问物理地址,即使它可能超过4GB.理想状况下,代码应该能快速并且简单地使用API来分配"高位"物理地址,创建或者移动窗口.这对于需要快速存取大量资料的应用程序来说想当地有帮助

　　在进程间共享高位内存将导致API和执行变得想当复杂.windows将避免这种分享

　　总之,对分页的支持使操作系统的设计和运行变得更加困难,而且使预计的性能更难以达到.windows将避免高位内存分页.

　　4.进程分支与共享内存

　　这个应用程序支持的模式将线程一分为二或者更多的相同副本.每一个副本都由用户栈,系统栈,分配的数据空间与寄存器构成,他们之间的主要的差别一个是有父进程的Process ID (PID),其它的是新的PID.这种分支返回一个PID的值.子系副本的这个PID值为0或是该子系PID是父系的副本.

　　5.PSE 36

　　通过使用内核设备驱动,比如一个RAM磁盘,在不对操作系统有任何变动的情况下使用超过4GB内存将变得可能.基础操作系统(以32位模式运行)与该驱动程序(以PAE模式执行)间的的相容性一直都是保持以分页表宽度为4 byte来做维持的.这样的操作换来了多个对于开发而言非常低的影响:

　　1.因为所有的I/o被强制执行双缓存而造成了效果的降低

　　2.应用程序开发上的影响不比现在的API的需求少

　　3.无法被当作"整合服务器"使用,因为所有的应用程序分享同一个4GB的物理内存空间..

　　设计的执行

　　操作系统为支持大内存做的操作必须直接处理这些问题才能成功.根据处理这些问题做出的设计抉择将直接影响操作系统的简易性,可靠性,及效能.

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

　　内存共享和进程内通讯

　　在所有用内存重映射来给进程分配内存的情况中--这对于许多PAE变量来说都很平常--共享内存都是有问题的.物理内存的重映射是发生在进程虚地址空间的"外部"的.因此,在分享线程的内部访问以及安全控制上,物理内存很少与进程联系起来,也很少和操作系统提供的联系起来.

　　为了提供访问和安全控制,就需要大量增加操作系统内存管理员使用的簿记(bookkeeping)和应用程序开发者必须使用的API设置,这对使用极快速重映射的操作的高性能性产生了负面的影响.千万记住,在任何情况下IPC/内存共享可能仍会在两个进程的虚地址空间之间发生,不管它们(或其中的一个)是否使用了物理映射的内存.

　　TLB 关闭

　　在一个多处理器系统中,当一个处理器改变了一个页表或页目录的条目,这个改变必须要通知所有其它的处理器。这个过程通常称为"TLB shootdown"。广播页表或页目录条目的改变可以通过基于内存的信号量或者处理器间中断(interprocessor interrupts, IPI)。

　　例如一个简单的,但是算法上是正确的TLB shootdown序列可能是下面的样子:

　　a.开始屏障(begin barrier)——除了一个处理器外停止所有处理器;让他们执行HALT指令或者空循环。

　　b.让那个没有停止的处理器改变PTE or PDE。

　　c.让所有处理器在他们各自TLB中修改的PTE, PDE失效。

　　d.结束屏障(end barrier)——恢复所有的处理器执行。

　　地址转换后备缓冲器(Translation Look-aside Buffers,TLBs)是处理器的寄存器,或者一个高速缓存,它提供一个直接的逻辑地址到物理地址的映射页表表项.一旦装载,处理器几乎不去读取分页目录(TLB没对上)除非发生工作项目切换.

　　当做重新映射操作时,确定所有的处理器都已经开启了逻辑到物理地址的映射时很有必要的.除此之外,重映射操作需要TLB关闭,因为重映射中,逻辑到物理地址的联合是无效的(逻辑=从应用程序/进程的角度看内存)

　　当一个或多个处理器重新装载TLB时会有效能上的影响.所有的操作系统都有这个问题,而且在PAE内存支持的情况下,他们通过几种不同的方式改善这个问题:

　　1. windows提供了让单一应用程序能够批处理多个重映射操作要求,好让它们全部在同一时间发生并且只引起一个TLB关闭和一次性能下降而不是可能多次任意发生的,且每次都会降低效能的重映射需求.者对于经常跑在单一目的系统上的大型应用程序尤其适合.

　　2.其它的操作系统提供了"受害者"缓冲区或是允许一个线程共享其它线程的映射,但是者必须付出更多同步与API复杂性的代价.

　　windows xp也提供了这种批处理或是分散/集合功能.除此之外,这些操作的效能在windows server 2003,Enterprise Editon 与 Datacenter Edition上有所改善.

　　I/O

　　在某种层次,所有的PAE变量和参与的驱动一起同时支持32-bit和64-bit DMA I/O 设备.但是这样附带很多前提和条件.

　　内核和内存结构

　　一般说来,内核存储空间结构是不会变更的,都是操作系统的标准内核.在很多情况下,像是存储池,大小也不会变.为了向下兼容,PCI型的地址寄存器(base address registers,BARs)也维持不变.更大的内存会造成某些内核地址空间的位移,这通常发生在当系统中介于16GB和32GB之间的内存为物理的时.

　　操作系统之间的一个差异就是内存的分配是否为动态的:

　　1.某些操作系统要求管理员为各种目的(快速缓存,映射,联合等等)设置内存的使用量

　　2.windows不要求管理员配置内存的分配,因为是动态的使用方式,而且在限制API使用的情况下运作.

　　硬件支持

　　PCI标准提供了一种方法通过适配器可以管理4GB以上的物理地址:将高32位地址和低32位地址分开传送.这被称为DAC(Dual Address Cycle),它同时被能解析64位地址但是只有32位地址线的32位适配器和确实拥有64位线的适配器所使用.这是一个硬件兼容性.

　　将这种方法用在PCI映射32位以外的地址上时,会有一种难以察觉的不足情况发生.任何跨2个4GB区域的I/O范围必须经过特别处理.如果不这样的话,只有一部分的地址范围会被正确的解码,而剩下的那些部分将会被转成错误的地址.这样腐蚀内存并且会导致系统,应用程序的崩溃,或是在不知觉的情况下损失该位置的数据.应用程序时无法防止这种事情的发生的,因为他们仅仅提供虚地址,而对物理地址是不可见的.所有使用PAE的操作系统都有这种问题,但是有些并不明确地防范这类问题,而是留给设备驱动来处理.

　　但是windows操作系统明确地防范了这类问题,当I/O范围的跨度处在这种情况的时候,windows返回两个分开的地址和范围到设备和驱动程序.最后的特殊案例是第一次转换超过4GB的地址.低于4GB的区域是不需要DAC的,但是余下的转换就需要DAC.windows将再次返回两个分开的地址和范围以防止内存崩溃.

　　显而易见,DAC或者64位的适配器和驱动在没有I/O缓存的时候提供了最好的效能.但是,一旦适配器和驱动不能利用超过32位地址的信息的时候,这个缓存是被要求有的.作为一个向下兼容的属性,所有使用PAE模式进行地址处理的操作系统都支持这个"双缓冲处理".这个缓存处理在效能上确实会损失一些,这取决于以下几个因素:

　　1.适配器硬件效能

　　2.驱动效能

　　3.操作系统对于双缓冲处理提供的支持.

　　4.系统中物理内存的使用量

　　随着物理内存的增加,相关的大于32bits的I/O地址相对于32bit以下的地址也同样增加了.在大部分情况下,操作系统显式地提供双缓冲,虽然一些Unix变量并不支持此功能,而且要求所有32位的设备和驱动自行管理他们自己的双缓冲程序和配置.

　　驱动问题

　　一般而言,设备驱动在许多地方都必须稍做修改,虽然真正的代码修改量式很少的,但是却有相当的难度.这是因为当不使用PAE内存寻址时,设备驱动可以假设物理地址和32位虚地址限制都是同样的.而PAE使这个假设不成立了.

　　一些预先能安全使用的假设和捷径不再适用了,通常,他们是在以下几个方面失效了:

　　1.分配和排列已共享缓存的缓存队列代码必须被修改,这样高于32位的物理地址才不会被忽略

　　2.要避免许多位置可能会保留不完整的地址信息的情况.

　　3.有必要严格地隔离虚拟和物理地址对应,这样DMA的操作就不会将信息传送到随即内存地址或者从随机地内存地址传回信息.

　　PAE模式可以在windows xp sp2,windows server 2003 sp1和随后的版本上启用,以支持硬件强制的DEP.但是,很多位这些系统设计的设备驱动可能并未在PAE开启的情况下测试过.为了减少对设备驱动兼容性的影响,windows XP SP2, windows server 2003 sp1 标准版对硬件抽象层(hardware abstraction layer, HAL)做了一些修改,限制物理内存最大为4GB.驱动开发者可以在http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx参考有关DEP的讯息

　　分页

　　大部分支持PAE的操作系统支持某些原始状态的虚拟内存分页以支持超过4GB的物理内存.这种情况经常随着一些限制条件发生,比如限制启动/系统 分页文件为4GB或者将分页文件分散在多个操作系统管理的卷上(并不一定非要是物理spindles)

　　虽然这样利用了显而易见的虚拟内存的优点,但是负面效果是对有以下一个或多个特性的应用程序的效能产生了影响.

　　1.使用大量的物理内存存储数据

　　2.有很多的I/O操作

　　3.有大量可执行工作组

　　最后就是,对分页的支持一般是以增加API组和减缓开发以及版本升级为代价的.

　　使用APIs

　　所有的支持PAE的操作系统都有能在IA-32处理器上让超过虚地址范围之外的进程使用物理地址的API.主要的差异在于它们能够提供多少先前提及的项目:内存共享,进程间通讯,分页,等等.windows提供了一个简单明了的API组--地址矿口扩展(AWE) API组.它由5个API调用组成,其中最复杂的API扩大了4倍,而且包括了内核和用户级调用

　　特有API的扩展--某些是与处理器架构直接相关的--使得应用程序从一个Unix变量传输到另外一个变得既昂贵又费时,而且还得不时地在花费和性能的最优化之间权衡.windows提供简单,快速并且非常轻便的可在32位和64位硬件平台上使用的API组,仅仅只需要重新编译一下就可以运作.

　　分页大小

　　几乎所有支持PAE的操作系统在提供超过4GB的物理内存给应用程序的时候都会使用不同大小的分页.除了windows以外,它在IA-32平台上只提供4KB的分页给应用程序使用(这和基于Itanium的平台是不同的)

　　应用程序使用变化的分页大小的问题与额外的应用程序复杂性有关,因为程序被要求在使用不同内存配置大小时仍能正常的运作,而且它还和绝大多数应用程序潜在的对页面大小的假设造成的不易察觉的作用有关.虽然研究表明,应用程序中一个小类能在更大的页面种获益(2MB或4MB),因为每个TLB条目跨越了一个更大的地址范围,一般的规则是,应用程序并不利用这种大页面受益.

　　Windows 和 PAE

　　windows 版本 支持

　　Windows 2000 Professional

　　Windows XP AWE API and 4 GB of physical RAM

　　Windows XP SP2 and later AWE API and 4 GB of physical address space

　　Windows 2000 Server

　　Windows Server 2003, Standard Edition AWE API and 4 GB of RAM

　　Windows Server 2003 SP1, Standard Edition AWE API and 4 GB of physical address space

　　Windows Server 2003, Enterprise Edition 8 processors and 32 GB RAM

　　Windows Server 2003 SP1, Enterprise Edition 8 processors and 64 GB RAM

　　Windows 2000 Advanced Server 8 processors and 8 GB RAM

　　Windows 2000 Datacenter Server 32 processors and 32 GB RAM (support for 64 GB was not offered because of a lack of systems for testing)

　　Windows Server 2003, Datacenter Edition 32 processors and 64 GB RAM

　　Windows Server 2003 SP1, Datacenter Edition 32 processors and 128 GB RAM