在《解析Windows 2000/XP物理内存管理》中我详细的介绍了页框数据库(Page Frame Database)的概念，提到在物理内存的组织与管理方面对于每个页面系统都在页框数据库中保存一个结构，用于跟踪页面状态等。但页框数据库并不能真正协调物理内存的使用。我们知道，Windows 是一个多任务的操作系统，而物理内存却是一个相对贫乏的资源，为避免某个进程(或是系统)耗尽这一资源，引入了工作集(WorkingSet)的概念。WorkingSet是内存管理一个相当重要的术语，在Windows 2000/XP 中通常分为两种即进程工作集与系统工作集，分别用于跟踪各个进程与系统的物理内存使用情况。由于终端服务的引入，另有一种工作集会话(Session)工 作集，用于跟踪各个Session使用物理内存的情况。本文从进程工作集的内部组织方式出发，简要阐述工作集在Windows 2000/XP中的组织与管理。
EPROCESS 是描述进程的结构，所以从EPROCESS入手，肯定也能找到进程工作集的表示方式。实际上位于EPROCESS中的子结构MMSUPPORT就是关于进 程与内存子系统相关的一些关键内容，进程工作集自然也在此。对于早期的内核版本这些内容没有集成至MMSUPPORT结构中，而且各版本间 MMSUPPORT的定义是不相同的，底下列出MMSUPPORT在Windows XP Build 2600 SP0中的定义(本文中所有结构都可能只适用于这一版本)：
typedef struct _MMSUPPORT {
LARGE_INTEGER LastTrimTime;
MMSUPPORT_FLAGS Flags;
ULONG PageFaultCount;
ULONG PeakWorkingSetSize;
ULONG WorkingSetSize;
ULONG MinimumWorkingSetSize;
ULONG MaximumWorkingSetSize;
PMMWSL VmWorkingSetList;
LIST_ENTRY WorkingSetExpansionLinks;
ULONG Claim;
ULONG NextEstimationSlot;
ULONG NextAgingSlot;
ULONG EstimatedAvailable;
ULONG GrowthSinceLastEstimate;
} MMSUPPORT, *PMMSUPPORT;
MMSUPPORT 中PeakWorkingSetSize、WorkingSetSize、MinimumWorkingSetSize与 MaximumWorkingSetSize分别表示此进程的工作集峰值、当然工作集大小、允许工作集的最大值与最小值。性能监视器 (perfmon.msc)与任务管理器(taskmgr.exe)都可对这些数据进程跟踪显示。 Win32 API GetProcessWorkingSetSize(Ex)和SetProcessWorkingSetSize(Ex)在具有相应 PROCESS_QUERY_INFORMATION与PROCESS_SET_QUOTA权限后即能获取或设置 MinimumWorkingSetSize与MaximumWorkingSetSize等。
进程在建立时，进程工作集总为空 的，CreateProcess等在建立进程过程中有责任初始化进程工作集。它会分配一个物理页面，然后调用 MiInitializeWorkingSetList初始化进程工作集。后者以刚建立的EPROCESS作为参数初始化我们上面提到的 MMSUPPORT结构。这里要提到一个很重要的成员VmWorkingSetList(结构MMWSL)，定义如下：
+0x000 Quota : Uint4B
+0x004 FirstFree : Uint4B
+0x008 FirstDynamic : Uint4B
+0x00c LastEntry : Uint4B
+0x010 NextSlot : Uint4B
+0x014 Wsle : Ptr32 _MMWSLE
+0x018 LastInitializedWsle : Uint4B
+0x01c NonDirectCount : Uint4B
+0x020 HashTable : Ptr32 _MMWSLE_HASH
+0x024 HashTableSize : Uint4B
+0x028 NumberOfCommittedPageTables : Uint4B
+0x02c HashTableStart : Ptr32 Void
+0x030 HighestPermittedHashAddress : Ptr32 Void
+0x034 NumberOfImageWaiters : Uint4B
+0x038 VadBitMapHint : Uint4B
+0x03c UsedPageTableEntries : [768] Uint2B
+0x63c CommittedPageTables : [24] Uint4B
效率上考虑，Windows 2000/XP 均将这一结构映射至一固定的虚拟内存地址中。由内核变量MmWorkingSetList指定，实际上 MiInitializeWorkingSetList就是直接引用这个变量对MMSUPPORT结构的VmWorkingSetList成员进行操作 的。MmWorkingSetList位于内核区域(在Windows XP Build 2600 Professional 中为0xc0503000)，通常内核区域均是由所有进程共享的，但显然MmWorkingSetList指定的WorkingSet情况对于每个进程都 有不同的映射，即具有不同的内容，这与进程页目录或是页表一样。后者我在《小议Windows NT/2000分页机制》中详细的做过测试。
因 为进程WorkingSet是用于描述进程使用物理内存的情况，换句话说位于WorkingSet中的页面均位于物理内存中(没有被置换到 pagefile.sys中等)，所以访问这些页面均不会导致Page Fault。我们可以使用VirtualLock将页面置入进程工作集中。反过来 想，系统如何知道某一页面(使用虚拟页面地址)，针对这一进程是否存在于工作集中呢？粗粗浏览一下上面给出的MMWSL的定义，就知道Windows 2000/XP使用哈希表(HashTable)来组织这些页面。HashTable具有快速检索的特点，正好适合于WorkingSet频繁访问的特点。另一个例子是系统全局命名内核的组织，详见《剖析Windows NT/2000内核对象组织》。与Windbg提供dump全局命令内核对象的!object命令一样，Windbg提供!wsle用于dump进程工作集。例如：
kd> !wsle 7
Working Set @ c0503000
FirstFree: 469 FirstDynamic: 7
LastEntry 46c NextSlot: 4 LastInitialized 658
NonDirect 145 HashTable: c06f4000 HashTableSize: 400
Reading the WSLE data...
..
Virtual Address Age Locked ReferenceCount
c0300203 0 1 1
c0301203 0 1 1
c0502203 0 1 1
c0503203 0 1 1
c0504203 0 1 1
c06f4203 0 1 1
c06f5203 0 1 1
c0505203 0 1 1
c0506203 0 1 1
77c47029 0 0 1
.
.
.
wsle 命令只是将VmWorkingSetList的Wsle成员(MMWSLE指针)指向的数组的每个元素dump出(每个元素32bit)。windbg 的!wsle命令获得的结果中Virtual Address列即Wsle的每一个32bit的内容。如下windbg命令所示：
kd> dd MmWorkingSetList l 1 //当前进程MMWSL结构所在的地址，如本文前头描述。
805467d0 c0503000
kd> dd c0503000 l 10 //MMWSL内容
c0503000 000003b9 000003ba 00000007 000003b9
c0503010 00000004 c050369c 00000658 0000014c
--------
|_MMWSLE内容(如上给出的MMWSL定义，MMWSLE是一个指针)
c0503020 c06f4000 00000400 0000001a c06f4000
| |_HashTableSize(Uint4B)哈希表大小
|_HashTable(MMWSLE_HASH)地址(底下将会用到这两个数值)
c0503030 c0800000 00000000 0000005c 004d023a
kd> dd c050369c
//结果即上面wsle命令输出的Virtual Address列(WorkingSet
//频繁变动，如果有稍许不同可能是系统已经更改过了)。
c050369c c0300203 c0301203 c0502203 c0503203
c05036ac c0504203 c06f4203 c06f5203 c0505203
实际上这里的每一个Virtual Address，就像上所示的如c0300203不仅仅是Virtual Address，因为WorkingSet是以页面为单位的，所以这些32bit的内容中有12bit用于其它用途。实际上在Windows XP中这个32bit的内容定义为MMWSLENTRY，具体为：
Valid : Pos 0, 1 Bit
LockedInWs : Pos 1, 1 Bit
LockedInMemory : Pos 2, 1 Bit
Protection : Pos 3, 5 Bits
SameProtectAsProto : Pos 8, 1 Bit
Direct : Pos 9, 1 Bit
Age : Pos 10, 2 Bits
VirtualPageNumber : Pos 12, 20 Bits
wsle命令也即根据这低12bit输出WSLE的一些属性：如Age与Locked。ReferenceCount则位于PFN中，具体请参阅《解析Windows 2000/XP物理内存管理》。
整 个结构至此已经比较明朗了，但是正像上面提到的WorkingSet访问是非常频繁的，在检索指定虚拟地址的页面是否在WorkingSet中还要依靠另 一个重要的成员HashTable。既然通过HashTable，我们来给出HashFunction(有兴趣想知道如何得到HashFunction的 可像我一样看看MiInsertWsle是如何实现的)。
((PVA >>a) & 0x3ffffc) % (HashTableSize-1)
这 里，PVA指页面虚拟地址，而HashTableSize指当前进程的WorkingSet哈希表的大小。对于给定的一个页面，如何在WSLE数组中快速 的检索到这个页面的数组下标呢？有了哈希表，当然通过Hash表了。这样描述还是比较抽象，我们以一个具体的例子说明问题：从上面wsle命令输出结果， 我们知道虚拟地址77c47000(77c47029那一行)，未于MMWSLE的第十项(数组下标为9，即index为9)，而这个进程的工作集 HashTableSize值为0x400(这个值可能系统会在需要时通常MiGrowWsleHash更改)，所以：
((77c47029>>a)&0x3ffffc) % (0x400-1)
值 为0x9a，所以位于HashTable的第0x9a个Bucket中(以0开始)，通过上面得到的HashTable地址c06f4000，找到第 0x9a个bucket。而每个Bucket的大小呢？需要说明的是这个HashTable的每个Bucket如下定义(_MMWSLE_HASH)：
+0x000 Key : Uint4B
+0x004 Index : Uint4B
即每个bucket为8个字节，所以我们用如下kd命令得到结果：
kd> dd c06f4000+9a*8 l 2
c06f44d0 77c47000 00000009
其Key值为77c47000，即虚拟地址，Index值为9，即验证了上面windbg的wsle命令输出结果。现在，对于WorkingSet的组织也已经讨论的差不多了，需要指出的是在Windows XP 中WorkingSet的设计远比这讨论的多很多内容，比如WorkingSet的哈希表是可扩展的(通过 MiGrowWsleHash)，HashTable内容的插入、更改、删除，还有工作集修整(通过MiTrimWorkingSet)等等，特别是工作 集修整，文章开头提到工作集的一个主要作用合理利用物理内存，避免某个进程(或是系统)耗尽物理内存，通过WorkingSet的最大、最小值与 Quota指定的限额，限定物理内存的使用。如果出现越出这样的一个范围或是物理内存耗尽，则会使用工作集修整。Andrew Tanenbaum的 《Modern Operating Systems》介绍了多种工作集修整的算法，在单处理器中Windows 2000/XP中使用了更像LRU的时候算法(Clock algorithm正像很多Unix系统实现一样)，你应该看到上面输出的Age的值吧。由于条件限制我只能在单处理器上实验过。为了篇幅完整，我简要介绍一下多处理器的情况：多处理中Windows 2000使用FIFO(First In First Out)算法，但从我看到的Microsoft的一些介绍中，似乎Windows XP/.Net Server 2003在多处理中也使用LRU了，看来Windows 的内核是越来越完善了。
本 文只介绍了进程工作集，对于系统工作集及Session工作集，大同小异，实际上我是在分析了三种工作集后，才开始着手写这样的一篇。这一些些的概念、结 构在自己的学习过程中不断被发现，也着实让自己兴奋不已，但我从来没有看过任何关于这些结构层次上的讨论，错误之处，在所难免，敬请见谅，谢谢!
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
