Huge pages and fragmentation

Assume hardware can represent both 4 KiB and 2 MiB page mappings. One 2 MiB mapping covers the same byte range as 512 base pages. A translation cache with an illustrative fixed number of entries can cover more bytes when its entries refer to larger pages. Actual processors often have different structures and capacities for different page sizes, so multiplying one common entry count is a teaching comparison, not a complete hardware model. Inspect the processor documentation and measure translation events relevant to the deployed configuration.

A large virtual mapping does not automatically become one large hardware page. It may still be backed by many base pages and their leaf entries. Conversely, a physical allocation can be larger than a base page without every supported kernel and architecture representing it through one higher-level hardware entry. Linux supports multiple mechanisms and page sizes. Report the observed mapping and allocation state, not merely an application hint. A successful advice call is not, by itself, evidence that every eligible byte is currently covered by the desired huge mappings.

Internal fragmentation is space within an allocated unit that the workload does not use. Touching a tiny fraction of many large regions can allocate far more backing than useful data, depending on the huge-page policy and its later splitting behavior. External physical fragmentation is different: sufficient free base pages may exist in total but not in a contiguous aligned run suitable for a particular large mapping. A contiguous virtual array can still be built from scattered base frames, so virtual continuity does not prove availability of a huge physical extent.

Compaction attempts to move eligible data so that free physical pages can be consolidated. Some pages cannot move under the relevant constraints, and compaction itself consumes time. A policy that permits synchronous work can produce a latency spike when an application asks for memory. Explicit HugeTLB pools have reservation and management rules distinct from transparent huge pages; they should not be described as the same allocator with a different flag. Check supported sizes, pool state, permissions, and deployment limits before relying on explicit allocations to succeed.

A dense, long-lived model buffer may amortize setup work and benefit from reduced translation pressure. A short-lived sparse pool may instead pay zeroing, copying, or waste costs without enough reuse to recover them. Compare the same workload with recorded page-size policies and actual page-size counters. Include peak physical memory, fault behavior, CPU cost, and allocation latency percentiles alongside throughput. A change that improves a steady-state benchmark can still violate a service's startup deadline or make memory packing less efficient across concurrent workers.

Use the probability lab for a narrow allocation-success thought experiment. Set twenty independent requests and success probability 0.8; predict sixteen modeled successful large allocations. Change probability to 0.5 and predict ten. Here probability is a supplied assumption, not a value inferred from total free RAM. Real requests compete for a changing physical layout, so their outcomes are correlated and the binomial model is not a fragmentation simulator. Explain which allocator statistics and controlled failure observations would be needed before assigning an empirical success probability.