Making kernel pages movable

vbabka — Mon, 27 Jul 2015 12:29:24 +0000

What you are suggesting does exist, and is called "grouping pages by mobility". Hugepage-large blocks of memory are marked with a "migratetype" as movable, unmovable, or reclaimable (for slab caches where freeing can be requested). All allocations declare their migratetype and the allocator tries to find free page in the matching block first.

But it's not a silver bullet. It works perfectly until free memory is exhausted and then you eventually find out that e.g. an unmovable allocation doesn't fit in any of the pageblocks marked as unmovable, and the allocation has to "fallback" to one of the partially free movable blocks. There are heuristic to select the fallback blocks that will result in lowest possible permanent damage - i.e. select a movable block that has the most free pages, and mark it as unmovable, so if there are more unmovable allocation requests, they can be satisfied from the same block, and not pollute another one.

Still it's just heuristics and can't be perfect without being able to predict the future. Consider an extreme case of your "gaps appear at deallocation only" scenario. There might be a surge of unmovable allocations that will occupy nearly the whole memory for a while, and then every odd page will be freed. The remaining even pages will now occupy half memory, but spread evenly in all pageblocks. If we knew at the allocation time that the even pages would be long-lived and the odd ones not, we could group them together. But we can't know that...

Making kernel pages movable

ksandstr — Fri, 24 Jul 2015 01:53:48 +0000

A stupid question: why not instead allocate immovable pages with preference for (hugepage grain & alignment) ranges that're guaranteed to already have an immovable page in them, thus only frustrating compaction to a reasonably minimized degree? This ought to work well because by definition every non-immovable page in such a range is free, movable, or discardable, so gaps appear at deallocation only.

(it's stupid because I'm assuming that status quo scatters immovable allocs around physical memory the same as e.g. anon memory for userspace.)

Upsides: no coöperation from allocators of immovable RAM. Impl is likely small, centralized, and applies to all consumers of immovable pages. Copies to relocate at alloc rather than at compact. Downsides: immovable memory remains immovable, so large allocations of immovable pages can't move shrapnel out of the way.

LWN: Comments on "Making kernel pages movable"

Making kernel pages movable

Making kernel pages movable