Re: [PATCH v3] mm: remove min_free_kbytes adjustment for THP

[Barry Song]

On Thu, Sep 3, 2026 at 12:04 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
[...]
>
> The idea is that the pageblock maintains contiguity for the largest
> size you routinely expect to allocate.
>
> The page allocator is very passive right now, and it doesn't work
> super reliably. But even in the current regime, smaller blocks have a
> better chance of containment.
>
> For example, when the ever-growing page cache runs out of movable
> block space, it spills into unmovable free space. When the next
> unmovable request finds no space, it runs LRU reclaim - which is more
> likely to free space in one of the many movable blocks. And so the
> next block is poisoned. Smaller blocks have a better chance of filling
> up natively, means less pressure to spill into incompatible ones.
>
> And the higher min_free_kbytes, the more likely there are still native
> options when the zones are down to the watermarks. E.g. better odds
> there is still unmovable free space, you just need to reclaim some
> movable/reclaimable space elsewhere to satisfy the watermarks.
>
> I've been working on making this more robust with the huge page
> allocator / defrag_mode stuff: instead of falling back and poisoning a
> block, invoke reclaim/compaction to produce a neutral block that can
> be converted entirely.
>
> It's the same idea as the higher min_free_kbytes and watermark
> boosting, but it is more targeted at the end result: readily available
> space in compatible or convertible blocks.
>
> But with that active regime, oversized pageblocks are even
> worse. You'd pay ongoing compaction work to produce a level of
> contiguity that you don't actually need.

Hi Johannes,

This could also be true when running 16KB or other mTHP sizes,
such as 32KB or 64KB, on a system with 4KB base pages and
2MB pageblocks.

Proactive compaction would try to create 2MB pageblocks, even
by migrating mTHPs, but 2MB isn't actually needed for large
folios on the system.

So here is an mTHP-friendly compaction RFC from Bo (Cc: Bo):
https://lore.kernel.org/linux-mm/20260825043833.2659350-1-zhangbo56@xxxxxxxxxx/

The idea is to let compaction create mTHP orders rather than
2MB pageblocks, with much lower cost and greater efficiency.

I'd be interested to hear if you have any comments on it.

Best Regards
Barry