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

[Nimrod Oren <noren@nvidia.com>]

On 02/09/2026 21:37, Johannes Weiner wrote:
> On Wed, Sep 02, 2026 at 06:00:55PM +0100, Lorenzo Stoakes (ARM) wrote:
>> On Wed, Sep 02, 2026 at 12:23:23PM -0400, Johannes Weiner wrote:
>>> I'm not against carefully evaluating and testing out today's need for
>>> set_recommended_min_free_kbytes() in real world examples. But this is
>>> not that.
>>>
>>> Nacked-by: Johannes Weiner <hannes@cmpxchg.org>
>>
>> Isn't every possible change to address this kind of issue subject to
>> exactly the same kind of constraint?
>>
>> I'd like to know what not rolling that dice looks like :) or what
>> constitutes 'careful evaluation'.
> 
> Usama gave some great examples in his other email. I'm not really
> arguing to keep things out of tradition. But I think it's fair to say
> let's at least test the common 4k/2M THP setups under memory pressure
> before and after the change.

Hi,

I tested this on an x86-64 (4K/2M) virtual machine with one NUMA node
and 16 GiB online memory, using mmtests config-workload-thpchallenge-fio
with THPCHALLENGE_MADV_HUGEPAGE=yes.
min_free_kbytes was 16 MiB patched and 66 MiB unpatched.

I ran each kernel 30 times, rebooting before each run. The results did
not show a regression in THP fault success rate or latency:

Average THP fault success (Percentage Faults Huge) increased from
13.07% unpatched to 13.34% patched, and average fault latency
(Fault Latencies) decreased by 6.5%.

In contrast, compaction metrics were higher on average with the patch:

  Compaction stalls:          1,635 -> 1,713        (+4.7%)
  Compaction failures:        1,350 -> 1,416        (+4.9%)
  Compaction migrate scanned: 4,812,254 -> 5,587,587 (+16.1%)

Thanks,