Re: [PATCH v2 3/4] mm: page_alloc: move capture_control to the page allocator

[Gregory Price]

On Wed, Jul 22, 2026 at 10:56:46AM -0400, Johannes Weiner wrote:
> From: "Vlastimil Babka (SUSE)" <vbabka@xxxxxxxxxx>
> 
> The compaction capturing code assumes the allocation request order and
> compaction target order are the same. That won't be true once
> defrag_mode promotes sub-block allocations to pageblock-order
> compaction: compaction targets the larger order, while capture should
> remain at the original allocation order.
> 
> Move the capture_control to the page allocator and give it its own
> copies of what the page freeing path matches against - zone, migratetype
> and the allocation order - rather than reaching into compaction's live
> compact_control. __alloc_pages_direct_compact() fills in migratetype and
> order, and installs and hides current->capture_control around the whole
> compaction call; try_to_compact_pages() aims capc->zone at each zone
> while it is being compacted. compact_zone_order() no longer deals with
> capture at all.
> 
> Pass the capture_control through try_to_compact_pages() /
> compact_zone_order() in place of the bare struct page **.
> 
> No functional change.
> 
> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
> Co-developed-by: Johannes Weiner <hannes@xxxxxxxxxxx>
> Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>
> ---
>  include/linux/compaction.h |  3 ++-
>  mm/compaction.c            | 50 +++++++++++---------------------------
>  mm/internal.h              |  4 ++-
>  mm/page_alloc.c            | 45 ++++++++++++++++++++++++++++------
>  4 files changed, 57 insertions(+), 45 deletions(-)
>
... snip ... 
> +		WRITE_ONCE(capc->zone, zone);
> +
>  		status = compact_zone_order(zone, order, gfp_mask, prio,
> -				alloc_flags, ac->highest_zoneidx, capture);
> +				alloc_flags, ac->highest_zoneidx, capc);
> +
> +		WRITE_ONCE(capc->zone, NULL);
> +
> +		/* Stop if a page has been captured */
> +		if (READ_ONCE(capc->page))
> +			status = COMPACT_SUCCESS;
> +

Might be worth a comment to explain what the WRITE/READ once is dealing
with here since it's now detached from the main barrier(), but otherwise

Reviewed-by: Gregory Price <gourry@xxxxxxxxxx>