Re: [PATCH] mm: thp: default defrag mode to defer+madvise

["Zi Yan" <ziy@nvidia.com>]

On Thu Aug 20, 2026 at 3:08 PM EDT, Ferran Duarri wrote:
> transparent_hugepage_flags unconditionally sets
> TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, so the built-in defrag mode
> is always "madvise" regardless of which of CONFIG_TRANSPARENT_HUGEPAGE_
> ALWAYS or _MADVISE was selected. Those Kconfig options choose whether
> THP is applied by default; they do not express a preference about how
> hard the allocator should work to produce a huge page, yet the defrag
> default is pinned as if they did.
>
> In "madvise" mode a fault on a MADV_HUGEPAGE region performs direct
> compaction in the fault path. Paired with transparent_hugepage=madvise
> that is a bounded cost, since only regions that asked for it are
> affected. Paired with transparent_hugepage=always every anonymous fault
> becomes eligible, and under memory pressure the faulting thread can
> stall in compaction.
>
> "defer+madvise" keeps the same set of regions eligible for huge pages
> and the same allocation attempt, but on failure it wakes kswapd and
> khugepaged to compact in the background instead of doing it inline. The
> fault proceeds with small pages and the region is collapsed later. This
> is the configuration long recommended to users running THP=always with
> large anonymous working sets, and it is a strictly weaker stall
> guarantee to make the default.
>
> This changes only the compiled-in default;
> /sys/kernel/mm/transparent_hugepage/defrag continues to accept every
> existing mode, including the current "madvise" behaviour.
>
> No stall measurement is offered with this patch. On the machine that
> prompted it the fault path never reaches direct compaction at all:
> thp_fault_alloc is 60682 against thp_fault_fallback 0, and compact_stall
> is 0, because memory has stayed abundant enough that no huge-page
> allocation has had to fall back. That makes the box unable to testify
> either way, and a number gathered under those conditions would measure
> nothing. The argument above is a correctness one about which knob the
> Kconfig choice is entitled to set, and it should be judged on that.
>
> Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
> ---
>  mm/huge_memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index b118bcd392cb..749f669cca56 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -63,7 +63,7 @@ unsigned long transparent_hugepage_flags __read_mostly =
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE_MADVISE
>  	(1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG)|
>  #endif
> -	(1<<TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG)|
> +	(1<<TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG)|
>  	(1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG)|
>  	(1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG);
>  

+Johannes, since he said Meta heavily rely khugepaged to make good use
of THP, he might give more insight here.

The patch adds additional kswapd/kcompactd work when a system fails to
allocate THP for non madvised THP-eligible memory regions. If the
system's CPU utilization is high, kswapd/kcompactd can take CPU
resrouces from others, right? Performance numbers are needed to justify
this change.

-- 
Best Regards,
Yan, Zi