Re: [RFC PATCH 2/4] mm: compaction: skip isolating large folios that satisfy the mTHP order

[Bo Zhang]

Thanks for the review. Replying to the two points below.

1) Build breakage when CONFIG_TRANSPARENT_HUGEPAGE is disabled

Sashiko says

"huge_anon_orders_always is only declared in include/linux/huge_mm.h under
CONFIG_TRANSPARENT_HUGEPAGE. Without an #else fallback stub, any kernel
build configured with CONFIG_COMPACTION=y and CONFIG_TRANSPARENT_HUGEPAGE=n
might fail with an undeclared identifier error."

Correct. In v2 the huge_anon_orders_always access is confined to
compact_hpage_order() and guarded by #ifdef CONFIG_TRANSPARENT_HUGEPAGE,
so this call site no longer references it directly.

2) Skipping isolation harms manual compaction and HugeTLB pool resizing

Sashiko says

"If smaller mTHPs (like order-2) are enabled, compact_hpage_order() will
return 2. This logic will then unconditionally return true for any folio of
order 2 or higher, skipping its isolation. Could this cause administrative
commands or automated HugeTLB pool resizing scripts to inexplicably fail to
allocate large contiguous memory blocks ...?"

To clarify the intent first: when mTHP is enabled the proactive compaction
target is compact_hpage_order() (e.g. order-2), so folios already at or
above that order need not be isolated - migrating smaller fragments is
enough to assemble the target block, and isolating larger folios is just
wasted work.

That said, the problem you describe is real: compact_hpage_order() is
derived from huge_anon_orders_always, so it also affects manual
`echo 1 > compact_memory` and HugeTLB pool resizing, which legitimately
want to form order-9/order-11 blocks.

This comes back to a question I raised in the cover letter: what is the
right way to determine the compaction target order? Deriving it from
huge_anon_orders_always is convenient but conflates mTHP proactive
compaction with these other callers. An alternative would be a dedicated
knob (e.g. a sysctl compaction target order). I haven't settled on the
right approach and would welcome opinions.

Bo