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

[Zi Yan <ziy@nvidia.com>]

On 2 Sep 2026, at 12:47, Usama Arif wrote:

> On 02/09/2026 17:04, Johannes Weiner wrote:
>> On Tue, Sep 01, 2026 at 09:49:58PM -0400, Zi Yan wrote:
>>> On 1 Sep 2026, at 18:09, Johannes Weiner wrote:
>>>
>>>> On Tue, Sep 01, 2026 at 05:09:52PM -0400, Zi Yan wrote:
>>>>> 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.
>>>>
>>>> That depends on whether anyone actually wants 512M pageblocks...
>>>>
>>>>> The ultimate solution is to enable better compaction to generate
>>>>> THPs bigger than a pageblock size, like Rik's super-pageblock
>>>>> proposal.
>>>>
>>>> ...or whether we can say, at that point, use gigablocks/cma+hugetlb.
>>>>
>>>> And then the static pageblock size for the fallback logic etc. can be
>>>> a smaller, saner default for everybody.
>>>>
>>>> Because the point you didn't address: it doesn't make really sense to
>>>> have 512M pageblocks on smaller machines, beyond the min_free_kbytes
>>>> issue: Fragmentation events will poison half a gig at once,
>>>> should_try_claim_block() becomes harder which results in less
>>>> conversions and more allocations falling through to stealing, page
>>>> isolation is more likely to fail, compaction locks and operates on
>>>> oversized chunks which is bad for latency and concurrency...
>>>
>>> I actually wonder why such a big pageblock would still result in a lot
>>> of fallbacks.
>>
>> If you look at try_to_claim_block(), you need half of a block to be
>> free or compatible with the requested migratetype in order to convert
>> it. When memory is full, LRU pages are scattered all over, and
>> compaction is not involved (order-0), this gets more difficult the
>> bigger the block is. You can get into a situation where LRU reclaim
>> will not clear sufficient room for conversion in any given pageblock
>> anymore and you're stuck with the type distribution. A large share of
>> buddy requests then go permanently through the slower fallback path.
>>
>> Usama knows more about this, but we have seen this on GB300 hosts, and
>> have JUST started to deploy kernels with smaller pageblocks (2M).
>
> Yes, just to confirm above, unfortunately, there were too many problems
> we were seeing in Meta production with 512M pageblock size for arm 64K
> base page size and just had to switch to 2M.

Do you mind elaborating on the problems? Johannes has given good arguments.
I would like to hear more from you, since he said you know more about the
issues.

Thanks.


Best Regards,
Yan, Zi