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

[Nimrod Oren <noren@nvidia.com>]

On 17/09/2026 16:49, Johannes Weiner wrote:
> On Thu, Sep 17, 2026 at 01:19:12PM +0300, Nimrod Oren wrote:
>> 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%)
> 
> A 2% increase in THP success bought with a 16.1% increase in
> compaction work looks like a sizable efficiency regression.
> 
> A scan efficiency drop is in line with expectations of what happens
> when non-frag placement reserves are taken from the allocator. A
> comparison of trace_mm_page_alloc_extfrag rates could be instructive.
> 
> Why the 2% success boost isn't quite clear to me. Allocation latency
> improving suggests the extra work is primarily picked up by background
> compaction. Reduced reserves could be making proactive compaction more
> aggressive. But the improvement is unlikely to hold once you run out
> of idle CPUs and the additional compaction work actually eats into the
> workload. It could be useful to look closer at who is doing the extra
> work and based on what triggers.

Thanks.

I ran another 30 pairs with the same setup and workload, this time
adding identical CPU load to both conditions. CPU utilization during
the measured workload averaged approximately 99.7% in both the baseline
and the patched runs. The aggregate mpstat %sys value averaged 2.25% in
the baseline runs and 2.22% in the patched runs.

THP results:

                              baseline avg  patched avg   change
  Percentage Faults Huge          9.92%        9.12%      -0.80 pp
  Fault Latencies               4923 us      4856 us      -1.36%

The average difference in Percentage Faults Huge changed from +0.26
percentage points in the earlier runs to -0.80 points under CPU load.
It's worth clarifying, though, that both differences were small relative
to the observed run-to-run variability: the baseline/patched standard
deviations were 4.52/4.59 percentage points earlier and 2.64/2.95
points under CPU load.

The same applies to Fault Latencies, whose baseline/patched SDs were
432/368 us earlier and 181/132 us under CPU load.

Compaction and reclaim results:

                              baseline avg  patched avg   change
  Compaction migrate scanned    3,983,598    4,563,788    +14.6%
  Kcompactd migrate scanned     1,242,728    1,944,022    +56.4%
  Compaction free scanned      17,689,565   20,461,694    +15.7%
  Kcompactd free scanned        2,608,710    4,426,810    +69.7%
  Compaction stalls                 1,476        1,514     +2.6%
  Compaction failures               1,265        1,319     +4.3%
  Direct pages scanned          1,339,044    1,344,907     +0.4%
  Kswapd pages scanned          2,011,323    2,141,355     +6.5%

End-to-end workload results:

                              baseline avg  patched avg   change
  Duration Elapsed                98.82 s      98.33 s      -0.50%
  Aggregate fio read bandwidth  0.2142 GiB/s  0.2152 GiB/s  +0.48%

Aggregate fio read bandwidth is the sum of the per-job read bandwidth
values in the fio output.