本文详细探讨了Windows 2000/XP操作系统的内存管理，尤其是原型PTE（Prototype PTE）的角色。通过原型PTE，系统能够有效地处理内存共享，特别是对于文件映射的情况。当多个进程需要访问同一文件时，Windows 2000/XP使用Section对象和PPTE表来实现共享，并避免频繁更新硬件PTE。在Page Fault处理过程中，通过软件模拟来处理指向PPTE的无效PTE，从而提高效率。文章还介绍了如何通过软中断和调试工具验证这一机制。
探究Windows 2000/XP原型PTE
WebCrazy(http://webcrazy.yeah.net)
内存管理可以说是操作系统实现中最重要的环节，也是最为复杂的一环节。对于相对贫乏的内存资源，内存共享也成了一个很重要的有效手段。Windows 2000/XP在此方面的实现借助于一个称为原型PTE(Prototype PTE，PPTE)的软件机制。在《小议Windows NT/2000分页机制》中我详细的介绍了Intel X86实现分段、分页的硬件PTE工作方式。我们来回顾一下这种机制：
假设我们的一个进程映射了从虚拟地址0xXXXXXXXX(假设位于分配粒度上)开始的4M空间，而这4M空间当前都相应的映射了实际的物理内存(鉴于Lazy evaluation等的先进思想，这种情况在Windows 2000/XP中比较少见)。我们将这4M空间分成1000块的4K(PAGE_SIZE，X86处理器决定)，对于第n个4K(0<=n<1000)，其虚拟地址(0xXXXXXXXX+n*4K)，我们都有一个对应的硬件PTE，指出目前这4K驻留于物理内存的位置。通过由PDBR(CR3寄存器)与虚拟地址可定位这个硬件PTE(具体请参阅《小议Windows NT/2000分页机制》)。
现在让我们来考虑这样一种情况，我们有一个文件其大小也为4M，我们知道通常我们要使用这个文件都要将它读入内存。试想同时有两个或更多的进程需读写这个文件，这就需要解决内存共享的问题。实际上就算当前只有一个进程访问这个文件，对于这种潜在的需要共享的文件，Windows 2000/XP均会事先考虑共享情况。她通过一个称为Section的内核对象来实现这样的目的。仔细想想，这种情况下内存共享决不仅仅是内存资源的充分利用，就算我们可以为每个进程各分配4M空间，但是这将导致各个进程某种时刻可能得不到这个文件的最新内容。这是非常糟糕的情况。在内部Windows 2000/XP利用原型PTE来解决这样的情况。基于硬件PTE相同的原理，对于这样一个4M的文件，在映射这个文件时，Windows 2000/XP同样的将这个文件分成1000块，每块4K(PAGE_SIZE)大小。然后从页交换区分配1000个DWORD，每个DWORD值都是原型PTE，它们组成原型PTE表。对于这个文件的第n个4K(0<=n<1000)，如果当前其驻留在物理内存中的话，其对应的PPTE的Valid位(bit 0，与硬件PTE一致)为1，然后这个PPTE的Page Frame Number(PPTE的高20位)用于指示物理内存。如果当前其仍然在磁盘中的话，Valid位为0。针对这种情况，通过PPTE的高20位(PFN Entry)，查找Page Frame Datbase(由MmPfnDatabase定位)，通过PFN Entry的Subsection PTE(windbg中称为restore pte,《Inside Windows 2000》中称为original pte，Windows XP内部称为Subsection PTE)，定位Subsection，然后通过Subsection指向的Control Area的FILE_OBJECT，与PPTE在PPTE表的偏移n，通过公式：
PFN Entry Subsection PTE->Subsection->Control Area->FileObject + n * 4K
定位所要访问的文件偏移，这样Windows 2000/XP使用页面调入IO读入这页内容，更新PPTE表的这个PPTE。以上的这一系列定位转换算法，如Subsection PTE如何定位Subsection，我将另行介绍。上面的描述解决了一个非常重要的问题，我们不需要更新所有引用这一页面的进程的硬件PTE，因为此时所有进程的PTE均指向PPTE，我们只要更新PPTE就能达到目的。至于进程PTE如何指向PPTE，下面我会涉及到这个内容。这儿你只要有一个概念，进程的PTE为了指向PPTE，肯定是一个Invalid PTE，即bit 0为0，而且其bit 10为1(PPTE标志，具体请看我在《探寻Windows NT/2000 Copy On Write机制》列出的HARDWARE_PTE_X86结构)。
WebCrazy(http://webcrazy.yeah.net)
内存管理可以说是操作系统实现中最重要的环节，也是最为复杂的一环节。对于相对贫乏的内存资源，内存共享也成了一个很重要的有效手段。Windows 2000/XP在此方面的实现借助于一个称为原型PTE(Prototype PTE，PPTE)的软件机制。在《小议Windows NT/2000分页机制》中我详细的介绍了Intel X86实现分段、分页的硬件PTE工作方式。我们来回顾一下这种机制：
假设我们的一个进程映射了从虚拟地址0xXXXXXXXX(假设位于分配粒度上)开始的4M空间，而这4M空间当前都相应的映射了实际的物理内存(鉴于Lazy evaluation等的先进思想，这种情况在Windows 2000/XP中比较少见)。我们将这4M空间分成1000块的4K(PAGE_SIZE，X86处理器决定)，对于第n个4K(0<=n<1000)，其虚拟地址(0xXXXXXXXX+n*4K)，我们都有一个对应的硬件PTE，指出目前这4K驻留于物理内存的位置。通过由PDBR(CR3寄存器)与虚拟地址可定位这个硬件PTE(具体请参阅《小议Windows NT/2000分页机制》)。
现在让我们来考虑这样一种情况，我们有一个文件其大小也为4M，我们知道通常我们要使用这个文件都要将它读入内存。试想同时有两个或更多的进程需读写这个文件，这就需要解决内存共享的问题。实际上就算当前只有一个进程访问这个文件，对于这种潜在的需要共享的文件，Windows 2000/XP均会事先考虑共享情况。她通过一个称为Section的内核对象来实现这样的目的。仔细想想，这种情况下内存共享决不仅仅是内存资源的充分利用，就算我们可以为每个进程各分配4M空间，但是这将导致各个进程某种时刻可能得不到这个文件的最新内容。这是非常糟糕的情况。在内部Windows 2000/XP利用原型PTE来解决这样的情况。基于硬件PTE相同的原理，对于这样一个4M的文件，在映射这个文件时，Windows 2000/XP同样的将这个文件分成1000块，每块4K(PAGE_SIZE)大小。然后从页交换区分配1000个DWORD，每个DWORD值都是原型PTE，它们组成原型PTE表。对于这个文件的第n个4K(0<=n<1000)，如果当前其驻留在物理内存中的话，其对应的PPTE的Valid位(bit 0，与硬件PTE一致)为1，然后这个PPTE的Page Frame Number(PPTE的高20位)用于指示物理内存。如果当前其仍然在磁盘中的话，Valid位为0。针对这种情况，通过PPTE的高20位(PFN Entry)，查找Page Frame Datbase(由MmPfnDatabase定位)，通过PFN Entry的Subsection PTE(windbg中称为restore pte,《Inside Windows 2000》中称为original pte，Windows XP内部称为Subsection PTE)，定位Subsection，然后通过Subsection指向的Control Area的FILE_OBJECT，与PPTE在PPTE表的偏移n，通过公式：
PFN Entry Subsection PTE->Subsection->Control Area->FileObject + n * 4K
定位所要访问的文件偏移，这样Windows 2000/XP使用页面调入IO读入这页内容，更新PPTE表的这个PPTE。以上的这一系列定位转换算法，如Subsection PTE如何定位Subsection，我将另行介绍。上面的描述解决了一个非常重要的问题，我们不需要更新所有引用这一页面的进程的硬件PTE，因为此时所有进程的PTE均指向PPTE，我们只要更新PPTE就能达到目的。至于进程PTE如何指向PPTE，下面我会涉及到这个内容。这儿你只要有一个概念，进程的PTE为了指向PPTE，肯定是一个Invalid PTE，即bit 0为0，而且其bit 10为1(PPTE标志，具体请看我在《探寻Windows NT/2000 Copy On Write机制》列出的HARDWARE_PTE_X86结构)。
最低0.47元/天 解锁文章
扫一扫
5402
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
