Re: [PATCH] mm/page_alloc: skip high atomic reservation at or below costly order

[JP Kobryn]

On 5/19/26 1:28 PM, Johannes Weiner wrote:
> On Mon, May 18, 2026 at 06:25:32PM -0700, JP Kobryn (Meta) wrote:
> > We're seeing a pattern in production where 2MB THP order-9 
> > allocations are
> > failing due to fragmentation and triggering reclaim on systems with 
> > plenty
> > of free memory. Over time, the success rate of these THP allocations 
> > do not
> > increase at all.
> >
> > Inspecting zone->vm_stat[NR_FREE_PAGES] via kprobe on 
> > compaction_suitable()
> > indicated the given zone had sufficient free pages for order-9 
> > allocations,
> > yet they were going unused. Drilling down into the zone and inspecting
> > /proc/pagetypeinfo revealed why. Order-9 blocks were accumulating in the
> > zone's HighAtomic bucket (while zero were present in Movable). THP is
> > unable to draw blocks from HighAtomic since that bucket is not in the
> > fallback list.
> >
> > The heuristic for reserving pageblocks in HighAtomic is that any atomic
> > allocation greater than order-0 will result in the full pageblock being
> > captured. This means that an order-1 atomic allocation will 
> > over-reserve by
> > 256x, a full 512 pageblock.
> >
> > Gate the reservation on order. Skip for allocations at or below
> > PAGE_ALLOC_COSTLY_ORDER. This prevents smaller atomic allocations from
> > reserving entire pageblocks, and significantly helps when THP is in 
> > use on
> > a fragmented but otherwise healthy system.
> >
> > Testing was performed using an A/B instagram workload receiving prod
> > traffic. Each side had ~60 hosts with 64G memory. The patch resulted in
> > several gains:
> >
> > Unpatched
> > HighAtomic pageblocks per host: 309-312 (1% of zone or 620MB),
> > ...all order-9 blocks in HighAtomic
> > THP success rate: 1-6%
> > Compaction success rate: 0-2%
> > pgscan_kswapd (total across ~60 hosts, per minute): ~70.2M
> > Atomic order-4+ allocations: 0
> >
> > Patched
> > HighAtomic pageblocks per host: 1
> > THP success rate: 44-78%
> > Compaction success rate: 24-47%
> > pgscan_kswapd (total across ~60 hosts, per minute): ~29.9M
> > Atomic order-4+ allocations: 0
> This is an interesting patch. A couple of thoughts:
>
> 1. You disabled the highatomic reserve for this workload and it didn't
> seem to matter. Presumably <costly orders don't need the protection.
Right. Although one detail I realize is I should also consider
pageblock_order as well to avoid any config issue.

> 2. Maxing out the reserves is odd. ALLOC_HIGHATOMIC allocations will
> try reserved space first, and I'd expect things that are commonly
> highatomic to be short-lived. Why don't we stop with a couple of
> claimed highatomic blocks that get continuously recycled?

Even though they may be short-lived, the data shows the volume of
allocations is steady enough to keep the reserves maxed out.

> 3. The impact on THP and compaction success rate is pretty
> extreme. How can 1% of memory throw such a wrench into the gears?
Looking at the pre-patched high atomic pageblock counts, that's ~300
pageblocks that could've been used for THPs. They become usable after
the patch.

> Have you tried this with other workloads?
No, but the pre-patch symptoms will show up on workloads where net
allocs are frequent enough to keep the high atomic pageblock count up.
Memory size of hosts involved is a factor as well since it's possible for a
majority of order-9 pages to be stuck in high atomic.