Re: [RFC PATCH 1/4] mm: compaction: make proactive compaction mTHP-aware

[Bo Zhang]

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

1) Build breakage when CONFIG_TRANSPARENT_HUGEPAGE is disabled

Sashiko says

"Does this break the build when CONFIG_TRANSPARENT_HUGEPAGE is disabled?
In include/linux/huge_mm.h, the declaration of huge_anon_orders_always is
guarded by #ifdef CONFIG_TRANSPARENT_HUGEPAGE, but here it is referenced
unconditionally."

You're right (the kernel test robot reported the same on m68k). In v2 I'll
guard the access with #ifdef CONFIG_TRANSPARENT_HUGEPAGE and fall back to
COMPACTION_HPAGE_ORDER.

2) __ffs() singles out the lowest enabled mTHP order

Sashiko says

"If an administrator enables both order-2 and order-9 THPs, it seems this
will return order-2, and __compact_finished() will halt compaction early
once enough order-2 blocks are formed, potentially starving the system of
order-9 THPs."

Yes, this is a deliberate simplification, also raised as an open question
in the cover letter. I don't have a firm answer on the best policy for
multiple enabled orders yet and would welcome opinions.

3) Racing with concurrent sysfs updates

Sashiko says

"kcompactd() caches the target order ... However, __compact_finished()
dynamically re-reads it here. If the target order changes mid-compaction
... Could this mismatch falsely indicate a lack of progress and erroneously
defer proactive compaction?"

Good catch. The clean fix would be to read the order once and plumb it
through the compaction path. But during proactive compaction target_order
is -1, and I couldn't find a clean way to pass the mTHP order down - which
is why the code reads huge_anon_orders_always directly. This is the open
question I raised in the cover letter; suggestions welcome.

Bo