咱们知道，在Config.bib装备中，RAM指定的内存区域会被划分为程序内存和目标存储。但在运用paging pool时，RAM段要减去paging pool的巨细，剩下空间再划分为程序内存和目标存储。其间程序内存首要为正在运转的程序保存堆和栈的内容。
那么paging pool是什么呢，运用paging pool有什么优点呢?在查阅了相关材料后谈谈我的一点知道，如有过错，也期望批评指正。(其间参阅了Sue Loh的《Paging and the Windows CE Paging Pool》一文，有爱好的能够看一下。)
先看一下paging pool的概念。Paging pool是RAM中reserved的一块区域。用于寄存pageale data(只读的可执行文件的代码，数据以及内存映射文件)。假如运用paging pool就会给pageale data所运用的内存设定约束，它还包含将pagable data从内存移出的算法机制。
在WinCE3.0曾经的体系，并没有运用paging pool。这意味着体系对保存pageable data所运用的RAM没有约束。那么假如运转很多的程序或拜访很多的内存映射文件时，内存运用率就会大大添加，直到体系耗尽内存，这时再分配内存就会失利。看起来如同内存真的用完了，但实际上还存在很多能够经过page data out然后开释的空间。最终，当体系抵达一个最低内存约束时，kernel就会把一切的pageble的数据悉数page out。这样突然间体系就会呈现很多可用内存，你要运用的数据就会经过产生page fault从头page in到内存。但这样会带来体系的不稳定。
因而WinCE引入了paging pool。The paging pool limits an amount of pageable memory system can has so it would be less thrashing prone. 运用paging pool，会设置有限的RAM用于寄存pageable的data。Pool的size设置太小，这意味着pages或许会被过早地page out，虽然他们依然在运用，然后引起频频的page fault。Pool巨细设置得太大，这意味着操作体系将保存更多的内存用于pageable data。这样就会削减page faults ，由于更多的代码存储在paging pool中。但Pool内存将无法被应用程序运用。
在CE 6.0中，虚拟内存的架构改变了，触及Windows CE的存储体系的重写，包含paging pool。CE 6.0的paging pool原理依然适当简略，但有一点愈加灵敏。CE 6.0有两个paging pools：loader pool用来寄存可执行代码，file pool用于寄存一切file-backed memory-mapped文件和CE6.0新增的文件cache过滤器，或许叫cache办理器。以这种方法，OEMs不光能够设置只读数据的内存运用量，而且能够设置read-write数据的内存运用量了。而且能够分别为代码和数据设置内存运用的约束。
这两个pool有几个参数。首要的参数是target size和maximum size。原理是操作体系总会确保pool具有至少target数量的内存运用。假如有剩余的可用内存，内核答应pool占有多于target的内存。可是当这种状况产生时，内核会唤醒一个低优先级的线程去page out一些数据，从头使pool渐渐降到target以下。选用这种方法，在busy “spikes”内存运用时，比方体系启动，体系会占用适当多的内存用来寄存pagable data。可是在steady-state，体系的pool内存运用量在target上下徜徉。Maximum size为内存耗费设置了硬性的约束。OEMs能够把这个maximum设的很大然后防止pool的约束。OEMs也能够把target和maximum巨细设置的相同，然后获取CE6之前的版别的paging pool的作用。
paging和paging pool是独立的。不论是不是paging pool都会产生paging。假如你封闭了paging pool，你也就关掉了用于paging的RAM的约束。可是pages依然能够paging。假如你翻开了paging pool，那么就会有约束。只不过关于paging pool，page in的data还能够page out。而关于非paging pool中的data则不会被page out。
ROM中的中的FILES中可执行文件的code和只读data将会运用pool。可执行文件中的R/W data不能被page out，所以不会运用paging pool。MODULES中的紧缩的可执行文件中的code和只读data也会运用pool。假如Image是从NOR或许RAM运转，MODULES中未紧缩的可执行文件将直接运转，而不运用pool。NAND中Image中MODULES中的可执行文件将会运用pool。
假如可执行文件被标志为“non-pagable”，则在加载时就会被page到RAM中，不会被page out，直到被卸载。这些Pages不运用pool。你也能够发明些“partially pagable”的可执行文件，经过告知linker使部分sections non-pagable。一般假如code和data是ISR的一部分，或许在suspend/resume时被调用，或被其他电源办理调用，就不能是pagable的，由于paging会形成体系溃散或死锁。假如code和data被IST拜访也不能是pagable，由于paging会影响实时性。
RAM-backed的内存映射文件不会运用Pool。在CE5或更老的版别中，只读的file-back mapfiles会运用Pool而R/W mapfiles不运用。在CE6中，一切的file-backed mapfiles都运用file pool。而且新的file cache filter(cache manager)会映射一切翻开的文件，所以cached file data也运用pool。
在CE5.0中，假如想运用paging pool，只需在Config.bib中界说如下：
#define PAGINGPOOLSIZE 00500000
cbNKPagingPoolSize 00000000 $(PAGINGPOOLSIZE) FIXUPVAR
即把paging pool的size设置为5MB。假如设置为0或许不设置的话，就没翻开paging pool，没有对寄存pageable的data和code的RAM的约束，作用和上面谈到的WinCE3.0之前没有paging pool时相同。不过主张运用paging pool。Pool的size设置是个难题，过大过小都不适宜。不过在CE 6.0中，假如将size设置为0的话，体系就会主动调理cbNKPagingPoolSize，这样就比较方便了。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/flyalice/archive/2009/02/16/3897253.aspx
