Page clustering is a form of "large pages" that increases the kernel's minimum allocation unit for physical memory (base page size). There are several good reasons to do this. One is a form of prefaulting accomplished by instantiating groups of PTE's mapping a given base page. Another is a constant factor reduction of the number of objects the kernel must traverse in order to manipulate a given collection of pages. The increase in
PAGE_SIZE also implies an increase in
PAGE_CACHE_SIZE, which enables the use of filesystems with larger blocksizes. Last, but not least, the constant factor reduction of lowmem consumed by
mem_map is crucial for the performance of 64GB i386 machines.
Page clustering has a number of technical challenges involved in a 2.5 counterpart of the 2.4.7 implementation. First, highpte poses unusual difficulties, as neither sub-
PAGE_SIZE highmem allocations nor sub-
PAGE_SIZE kmapping were supported in the original implementation. Rmap also poses challenges, as it makes direct assumptions about PTE's being of size
PAGE_SIZE. Finally, arch code above all makes many assumptions about
PAGE_SIZE's relationship to the area mapped by PTE's, particularly in arch support and VM initialization code.
In summary, the author will describe the problems that arose during his implementation of page clustering for 2.5 along with their solutions, for an audience of kernel programmers.