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

[Zi Yan]

On 1 Sep 2026, at 16:44, Johannes Weiner wrote:

> 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.

But lowering pageblock size requires a kernel compilation. That means
maintaining two sets of kernels for different needs. The ultimate
solution is to enable better compaction to generate THPs bigger than
a pageblock size, like Rik's super-pageblock proposal.

After removing automatic min_free_kbytes boosting, user can still
increase it via sysctl to restore the old free memory head room.
It is much easier, right?

>
>> 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?

Extra free memory is still necessary. min_free_kbytes can be adjusted
at machine boot time to achieve it, right?

Best Regards,
Yan, Zi