注册
登录
| 关键词： 进程 工作 MMSUPPORT 内存 物理 内核 页面 Uint WorkingSet 结构 |
在《解析Windows2000/XP物理内存管理》中我详细的介绍了页框数据库(PageFrameDatabase)的概念，提到在物理内存的组织与管理方面对于每个页面系统都在页框数据库中保存一个结构，用于跟踪页面状态等。但页框数据库并不能真正协调物理内存的使用。我们知道，Windows是一个多任务的操作系统，而物理内存却是一个相对贫乏的资源，为避免某个进程(或是系统)耗尽这一资源，引入了工作集(WorkingSet)的概念。WorkingSet是内存管理一个相当重要的术语，在Windows2000/XP中通常分为两种即进程工作集与系统工作集，分别用于跟踪各个进程与系统的物理内存使用情况。由于终端服务的引入，另有一种工作集会话(Session)工作集，用于跟踪各个Session使用物理内存的情况。本文从进程工作集的内部组织方式出发，简要阐述工作集在Windows2000/XP中的组织与管理。EPROCESS是描述进程的结构，所以从EPROCESS入手，肯定也能找到进程工作集的表示方式。实际上位于EPROCESS中的子结构MMSUPPORT就是关于进程与内存子系统相关的一些关键内容，进程工作集自然也在此。对于早期的内核版本这些内容没有集成至MMSUPPORT结构中，而且各版本间MMSUPPORT的定义是不相同的，底下列出MMSUPPORT在WindowsXPBuild2600SP0中的定义(本文中所有结构都可能只适用于这一版本)：typedefstruct_MMSUPPORT{LARGE_INTEGERLastTrimTime;MMSUPPORT_FLAGSFlags;ULONGPageFaultCount;ULONGPeakWorkingSetSize;ULONGWorkingSetSize;ULONGMinimumWorkingSetSize;ULONGMaximumWorkingSetSize;PMMWSLVmWorkingSetList;LIST_ENTRYWorkingSetExpansionLinks;ULONGClaim;ULONGNextEstimationSlot;ULONGNextAgingSlot;ULONGEstimatedAvailable;ULONGGrowthSinceLastEstimate;}MMSUPPORT,*PMMSUPPORT;MMSUPPORT中PeakWorkingSetSize、WorkingSetSize、MinimumWorkingSetSize与MaximumWorkingSetSize分别表示此进程的工作集峰值、当然工作集大小、允许工作集的最大值与最小值。性能监视器(perfmon.msc)与任务管理器(taskmgr.exe)都可对这些数据进程跟踪显示。Win32APIGetProcessWorkingSetSize(Ex)和SetProcessWorkingSetSize(Ex)在具有相应PROCESS_QUERY_INFORMATION与PROCESS_SET_QUOTA权限后即能获取或设置MinimumWorkingSetSize与MaximumWorkingSetSize等。进程在建立时，进程工作集总为空的，CreateProcess等在建立进程过程中有责任初始化进程工作集。它会分配一个物理页面，然后调用MiInitializeWorkingSetList初始化进程工作集。后者以刚建立的EPROCESS作为参数初始化我们上面提到的MMSUPPORT结构。这里要提到一个很重要的成员VmWorkingSetList(结构MMWSL)，定义如下：+0x000Quota:Uint4B+0x004FirstFree:Uint4B+0x008FirstDynamic:Uint4B+0x00cLastEntry:Uint4B+0x010NextSlot:Uint4B+0x014Wsle:Ptr32_MMWSLE+0x018LastInitializedWsle:Uint4B+0x01cNonDirectCount:Uint4B+0x020HashTable:Ptr32_MMWSLE_HASH+0x024HashTableSize:Uint4B+0x028NumberOfCommittedPageTables:Uint4B+0x02cHashTableStart:Ptr32Void+0x030HighestPermittedHashAddress:Ptr32Void+0x034NumberOfImageWaiters:Uint4B+0x038VadBitMapHint:Uint4B+0x03cUsedPageTableEntries:[768]Uint2B+0x63cCommittedPageTables:[24]Uint4B效率上考虑，Windows2000/XP均将这一结构映射至一固定的虚拟内存地址中。由内核变量MmWorkingSetList指定，实际上MiInitializeWorkingSetList就是直接引用这个变量对MMSUPPORT结构的VmWorkingSetList成员进行操作的。MmWorkingSetList位于内核区域(在WindowsXPBuild2600Professional中为0xc0503000)，通常内核区域均是由所有进程共享的，但显然MmWorkingSetList指定的WorkingSet情况对于每个进程都有不同的映射，即具有不同的内容，这与进程页目录或是页表一样。后者我在《小议WindowsNT/2000分页机制》中详细的做过测试。因为进程WorkingSet是用于描述进程使用物理内存的情况，换句话说位于WorkingSet中的页面均位于物理内存中(没有被置换到pagefile.sys中等)，所以访问这些页面均不会导致PageFault。我们可以使用VirtualLock将页面置入进程工作集中。反过来想，系统如何知道某一页面(使用虚拟页面地址)，针对这一进程是否存在于工作集中呢？粗粗浏览一下上面给出的MMWSL的定义，就知道Windows2000/XP使用哈希表(HashTable)来组织这些页面。HashTable具有快速检索的特点，正好适合于WorkingSet频繁访问的特点。另一个例子是系统全局命名内核的组织，详见《剖析WindowsNT/2000内核对象组织》。与Windbg提供dump全局命令内核对象的!object命令一样，Windbg提供!wsle用于dump进程工作集。例如：kd>!wsle7WorkingSet@c0503000FirstFree:469FirstDynamic:7LastEntry46cNextSlot:4LastInitialized658NonDirect145HashTable:c06f4000HashTableSize:400ReadingtheWSLEdata.....VirtualAddressAgeLockedReferenceCountc0300203011c0301203011c0502203011c0503203011c0504203011c06f4203011c06f5203011c0505203011c050620301177c47029001...wsle命令只是将VmWorkingSetList的Wsle成员(MMWSLE指针)指向的数组的每个元素dump出(每个元素32bit)。windbg的!wsle命令获得的结果中VirtualAddress列即W |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
