Best Page Pool Size for Windows Mobile 6.5

This article provides an overview of page pool optimization in Windows Mobile 6.5 custom ROMs, detailing how modifying the page pool size impacts system speed and available memory. It explores the technical trade-offs between responsiveness and free program RAM, outlines the ideal page pool configurations for various device tiers, and examines why specific adjustments improved everyday usability on legacy devices.

Understanding the Page Pool in Windows Mobile

In Windows Mobile 6.5 (based on Windows CE 5.2), the page pool is a dedicated block of RAM set aside by the kernel (nk.exe) to cache executable code and file data decompressed from the device’s flash ROM.

When an application or OS component is called, the system retrieves it from storage. If a page pool is active, the uncompressed pages are held in this fast-access buffer. Without a sufficient buffer, the CPU is forced to repeatedly decompress data from slow NAND storage, resulting in noticeable UI stutter and app launch delays.

The Core Trade-Off: RAM vs. Responsiveness

Page pool modification was one of the most prominent tweaks performed by custom ROM chefs (notably within the XDA-Developers community) using tools like PagePool Changer. Adjusting the size involved a direct trade-off:

  • Larger Page Pool: Greatly reduces disk read cycles, accelerates UI animations (particularly resource-heavy interfaces like HTC Sense 2.5 and TouchFLO 3D), and speeds up task switching. However, every megabyte assigned to the page pool is directly subtracted from user-accessible program RAM.
  • Smaller Page Pool: Leaves more free RAM to run multiple or heavy third-party applications simultaneously, reducing "Out of Memory" errors. The downside is increased system lag, slower scrolling, and frequent micro-stutters.
  • Dynamic Page Pool (0 MB setting): Some ROMs allowed a dynamic page pool (often labeled as 0 MB), allowing the kernel to allocate cache space on demand. While this maximized free RAM on paper, the constant dynamic allocation caused severe frame drops and inconsistent performance during routine navigation.

Optimal Page Pool Sizes by Device Class

Performance gains depended on the physical RAM available on the target device. The community established several standardized sweet spots:

1. Low-RAM Devices (128 MB Total RAM)

  • Devices: HTC Touch Diamond, HTC Kaiser (TyTN II), HTC Touch Cruise
  • Default Stock Setting: Often 4 MB to 8 MB, or set to dynamic allocation.
  • Optimal Adjustment: 4 MB to 6 MB
  • Result: Devices with only 128 MB of physical RAM had extremely tight memory budgets, often leaving only 40–50 MB of usable RAM after boot. Reducing the page pool to 4 MB or 6 MB provided the best compromise, granting a crucial 4–6 MB of extra RAM back to the user without making the Start menu and dialer completely unresponsive.

2. Mid-Tier Devices (256 MB to 288 MB Total RAM)

  • Devices: HTC Touch Pro, HTC Touch HD (Blackstone), HTC Touch Pro2 (Rhodium)
  • Default Stock Setting: 8 MB to 12 MB
  • Optimal Adjustment: 8 MB to 12 MB
  • Result: With around 200 MB of usable memory, RAM scarcity was less critical. Setting the page pool to 8 MB allowed smooth kinetic scrolling and stable operation of HTC Manila (Sense 2.1). For users running heavier Sense 2.5 ports with animated weather widgets, 12 MB was preferred to eliminate launcher redraw delays.

3. High-End Devices (448 MB to 576 MB Total RAM)

  • Devices: HTC HD2 (Leo)
  • Default Stock Setting: Varied between carrier releases (typically 12 MB to 16 MB).
  • Optimal Adjustment: 16 MB to 24 MB (with 18 MB widely considered optimal)
  • Result: The HTC HD2 had abundant RAM for a Windows Mobile handset. Allocating 16 MB to 18 MB allowed the entire graphics layer, touch input drivers, and Sense 2.5 shell to operate almost entirely out of cached memory. This eliminated home-screen redraws and produced a fluid 60 FPS scrolling experience throughout Windows Mobile 6.5.

Summary of Performance Improvements

Adjusting the page pool produced measurable performance improvements across Windows Mobile 6.5 ROMs:

  1. Elimination of Launcher Redraws: Increasing the pool to 12 MB+ on capable hardware stopped the OS from killing and reloading the home screen shell when exiting an application.
  2. Reduced Flash Wear and Battery Consumption: Keeping active system binaries in RAM minimized read operations to the physical NAND flash, conserving power and extending hardware longevity.
  3. Optimized Multitasking: Lowering the pool on 128 MB devices prevented background processes (such as email synchronization and messaging clients) from being prematurely terminated by the OS due to low-memory thresholds.