Paging Pool: Windows CE 5.0 vs. Windows Embedded CE 6.0

Other versions of this page are also available for the following:

• Windows Embedded CE 6.0 R3

8/28/2008

This topic describes the differences between the paging pool in Windows CE 5.0 and Windows Embedded CE 6.0.

Previous Versions of the OS

In Windows CE 5.0, the paging pool was a fixed-size portion of memory reserved for executable code and read-only, memory-mapped files. If the amount of code loaded into memory at any time was smaller than the pool, the pool did not shrink to match. Similarly, if the amount of coded loaded at any time was larger than the pool, only the most recently used pages were held in memory, up to the size of the pool. The pool did not grow to hold more code, so executable code discarded. OEMs controlled the size of the paging pool with an OEM adaptation layer (OAL) variable, cbNKPagingPoolSize.

In Windows CE 5.0 and earlier, the page pool maintained a physically contiguous range of pages and kept an array of information to track each page in the pool. Pages were kept in a global first-in, first-out (FIFO) list, and in a list per module for quick discarding of a module on unload.

Current Version of the OS

In CE 6.0, the page pool is a count of pages used by the pool. The pool has a target size, but can grow above or shrink below the target. The pool is accompanied by a trimming thread, which runs whenever the pool is above its target. The trimming thread discards pages to reduce the pool back to its target. The physical memory manager reserves the target number of pages for the pool so that it is guaranteed to be able to grow to that size.

The CE 6.0 paging pool differs from previous OS versions in two primary ways:

• The pool can temporarily exceed its reserved size. Rather than setting a single size for the pool, an OEM can now choose a target size for the pool, plus a maximum size. There is always enough memory reserved for the pool to grow to reach its target. Above that, if memory is available the pool continues to grow, up to the maximum limit. The pool never exceeds the maximum. As soon as the pool exceeds the target, the kernel wakes up a trimming thread that walks through modules and discards pages. The trimming thread runs at low priority normally, so that paging operations do not disturb other system activity. If the pool approaches its maximum limit, the trimming thread runs at higher priority temporarily to ensure that pool memory is released.
• There are now two pools. One pool, the loader pool, holds executable code and read-only, memory-mapped files as did the Windows CE 5.0 paging pool. A second pool, the file pool, holds data pages from memory-mapped files and from the new CE 6.0 file system cache manager. The file pool is different from the loader pool in that its pages may also be read/write, so they may need to be written back to disk before being discarded. Therefore, the file pool can be configured separately from the loader pool to maximize system performance. Because file writes are relatively slow operations, the file pool trimming thread runs at lower priority than the loader pool trimming thread.

In CE 6.0 the OAL variable cbNKPagingPoolSize is deprecated. Instead, to configure paging pool parameters, OEMs can implement a new IOCTL in their OAL: IOCTL_HAL_GET_POOL_PARAMETERS. If the OAL does not implement this IOCTL, the kernel chooses suitable default settings. The kernel also exposes information about the current state of the paging pool to applications through the new kernel IOCTL IOCTL_KLIB_GET_POOL_STATE. Applications can call this IOCTL to query current memory usage and other state information about the paging pools.

See Also

Other Resources

Kernel Functionality Modifications: Windows CE 5.0 vs. Windows Embedded CE 6.0
File and Disk Caching
Bringing Up a Hardware Platform
Developing a Device Driver