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

Bad computer. Go sit in the corner, and think about your life!

https://youtu.be/_8c58JZQ4Bs?si=mA66nH1swfK9eRML


have a nice weekend,

Ferran


On 8/21/26 6:53 PM, Lorenzo Stoakes (ARM) wrote:
> No. We don't randomly change core mm defaults like this especially not on the
> behest of AI schlop...
>
> On Thu, Aug 20, 2026 at 09:08:23PM +0200, 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.
> It's not pinned. Distros change these as they please.
>
> That's where any such change should be.
>
>> 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
> Not really that bounded in practice.
>
>> affected. Paired with transparent_hugepage=always every anonymous fault
>> becomes eligible, and under memory pressure the faulting thread can
>> stall in compaction.
> What? No?
>
>> "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
> If we felt it was right to set this a default we would have...
>
>> 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.
> None of this judstifies anything.
>
>> 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.
> This sentence is truly ludicrious...!
>
> Made me laugh a bit though which is something at least.
>
>> Signed-off-by: Ferran Duarri <[email protected]>
> You:
>
> - Only started posting patches yesterday
> - Have posted patches all over the kernel
> - Post walls of text that read exactly like they are AI-generated
> - Are trying to change a fundamental default, not as an RFC, not citing any
>    actual workloads
>
> Go away and read:
>
> https://docs.kernel.org/process/coding-assistants.html
> https://docs.kernel.org/process/generated-content.html
>
> Then ideally just go away.
>
> We don't want AI slop patches from people who have no understanding of what
> they're changing, thanks!
>
>> ---
>>   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);
>>
> --
> Cheers, Lorenzo