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

[Usama Arif <usama.arif@linux.dev>]

On 02/09/2026 18:02, Zi Yan wrote:
> 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.
The issue that finally pushed us toward 2 MiB pageblocks occurred on
GPU hosts during AI-training checkpointing. We observed significant
latency spikes and workload timeouts.

These hosts had substantial unmovable memory, and order-0 allocations
from TCP paths repeatedly fell back to MIGRATE_MOVABLE free lists.
With 512 MiB pageblocks, try_to_claim_block() often could not meet
the half-pageblock threshold, so allocation fell through to stealing
individual pages.

This contaminated very large movable pageblocks with unmovable pages.
Compaction then repeatedly scanned those pageblocks but could not
evacuate the unmovable allocations. We observed sustained compaction
activity during the latency spikes.

> 
> Thanks.
> 
> 
> Best Regards,
> Yan, Zi