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

[Nimrod Oren]

On 20/09/2026 16:17, Nimrod Oren wrote:
> 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@xxxxxxxxxxx>
>>>>>
>>>>> 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.

Following up with tracing data.

I ran another eight baseline/patched pairs with the same
thpchallenge-fio workload, without additional CPU load.

For mm_page_alloc_extfrag, the mean was 3,334 events/second baseline
and 3,586 patched. The patched rate was higher in six pairs and lower
in two. The pairwise changes ranged from -1,281 to +1,943 events/second.

I extended mm_compaction_end identically in both kernels to record
total_migrate_scanned and the direct_compaction and
proactive_compaction flags.

Summing total_migrate_scanned per run gave these averages:

                              baseline avg  patched avg
  proactive kcompactd           2,826,839     3,145,912
  non-proactive kcompactd         235,081       275,834
  direct compaction             2,518,875     2,295,135

Proactive and non-proactive kcompactd scanning were higher with the
patched kernel in five of eight pairs each, while direct scanning was
lower in six of eight.