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

[Johannes Weiner <hannes@cmpxchg.org>]

On Tue, Sep 01, 2026 at 10:01:23PM +0300, Nimrod Oren wrote:
> When THP is enabled, set_recommended_min_free_kbytes() may raise
> min_free_kbytes using a heuristic that scales with pageblock_nr_pages.
> Commit f000565adb77 ("thp: set recommended min free kbytes") added this
> heuristic to help keep pageblocks free and reduce fragmentation for THP
> allocations.

We've had problems with compaction before when min_free_kbytes was too
small on large machines. Competing free space scanners do a lot of
work only to fight over a very small set of possible target pages.

So I'm a bit uneasy that you didn't include any benchmark numbers with
this that prove basic functionality on larger hosts isn't regressed.

> The recommendation scales poorly with larger base page sizes. With the
> default arm64 pageblock sizes, the contribution per eligible zone
> before applying the existing cap of 5% of low memory is:
> 
>   4 KiB pages:   2 MiB pageblock,   22 MiB per zone
>  16 KiB pages:  32 MiB pageblock,  352 MiB per zone
>  64 KiB pages: 512 MiB pageblock,  5.5 GiB per zone

I question whether pageblocks need to be 512M on those machines to
begin with. After this patch, you're still asking the page allocator
to optimize grouping such that 512M pages can be allocated at
runtime. Only now you took away part of the mechanism to do so.

If you're using 512M THPs, I would kind of assume it's on machines
with a memory size where 5.5G for defrag purposes isn't devastating.

And if you're not, it would make more sense to lower the pageblock
size to the mTHP size you're actually using. And that would fix the
"excessive" min_free_kbytes issue as well.

> The automatic min_free_kbytes increase predates proactive compaction
> and many subsequent changes to compaction. Given those changes,
> increasing min_free_kbytes for THP by default is no longer clearly
> justified.

That's pretty handwavy. How would these changes specifically eliminate
the need for compaction scratch space and allocator fallback options
to stave off fragmentation during placement?