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

[Johannes Weiner]

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.