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

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

[Ferran Duarri]

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);
 

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

[Zi Yan]

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

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

[Lorenzo Stoakes (ARM)]

On Thu, Aug 20, 2026 at 04:15:30PM -0400, Zi Yan wrote:
> 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.

This patch is completely ludicrious so not really worth considering beyond the
moot discussion points.

People have seen really significant issues when changing this setting, it's very
sensitive, and distros can set as needed. :)

But maybe there's an interesting discussion to be had?

>
> --
> Best Regards,
> Yan, Zi
>

--
Cheers, Lorenzo

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

[David Hildenbrand (Arm)]

On 8/20/26 21:08, 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);
>  

Why are such defaults not better changed in the distributions or by the users in
their boot system config? Why is there a need for us to change the default in
the kernel?

-- 
Cheers,

David

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

[Ferran Duarri]

Please drop this one, and not for the reason you asked about. Your mail
sent me back to read the code properly, and my commit message has the
mechanism backwards.

I claimed:

> Paired with transparent_hugepage=always every anonymous fault
> becomes eligible, and under memory pressure the faulting thread can
> stall in compaction.

That doesn't happen. In vma_thp_gfp_mask(), the current default:

	/* Only do synchronous compaction if madvised */
	if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, ...))
		return GFP_TRANSHUGE_LIGHT |
		       (vma_madvised ? __GFP_DIRECT_RECLAIM : 0);

A non-madvised fault gets GFP_TRANSHUGE_LIGHT with no reclaim flag at all,
so it fails fast and cannot stall in direct compaction. The stall I
described is only reachable from a MADV_HUGEPAGE region, and defer+madvise
keeps __GFP_DIRECT_RECLAIM for exactly those regions:

	if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, ...))
		return GFP_TRANSHUGE_LIGHT |
			(vma_madvised ? __GFP_DIRECT_RECLAIM :
					__GFP_KSWAPD_RECLAIM);

So the patch removes no stall. What it actually changes is the other
branch: non-madvised faults gain __GFP_KSWAPD_RECLAIM, which they did not
have. That is strictly more background work, waking kswapd and kcompactd
on failed THP allocations across every anonymous fault under THP=always.
The patch does close to the opposite of what it claims, and on a
fragmented machine it is a plausible regression rather than an
improvement.

transhuge.rst says the same thing I should have read before writing the
commit message: madvise "will enter direct reclaim like always but only
for regions that are have used madvise(MADV_HUGEPAGE)".

Zi Yan, that also answers your question, and you were right to ask it: the
extra kswapd and kcompactd work you identified is the real effect of the
patch, not a side cost of it.

One correction to my own patch while I am here. I wrote that the machine
could not testify: thp_fault_fallback 0 across 60682 faults, compact_stall
0. That was true when I sent it and is not true now. Same box, THP=always,
64 GB, after a few hours with a 27B model resident:

	thp_fault_alloc     213690
	thp_fault_fallback   22145
	compact_stall         3762
	compact_fail          1926

So it does reach the fallback path, it just had not yet. I am not offering
that as evidence for anything: it was collected with defer+madvise already
in effect, so it says nothing about what madvise would have done, and
defrag is writable at runtime, so the A/B costs nothing. If I get
something worth showing, it will be a fresh patch with numbers in it, not
this one.

Lorenzo, no argument on the patch. It is wrong for the reason above and I
would rather have found that before sending than after.

On "distros can set as needed", that is the one part I would push back on,
and it is the same thing David asked. They cannot, other than by writing
to sysfs after boot. There is no Kconfig symbol for defrag; mm/Kconfig
offers only the ALWAYS/MADVISE/NEVER enablement axis. There is no boot
parameter either: setup_transparent_hugepage() sets
TRANSPARENT_HUGEPAGE_FLAG and TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG only, and
thp_anon= is a different axis again. Grepping for what sets the DEFRAG
bits at all outside the initialiser, it is defrag_store() and nothing
else. So a distro that wants a different defrag default ships a sysfs
unit, and anything faulting between subsys_initcall(hugepage_init) and
that unit gets the compiled-in value.

That may well be deliberate and sufficient. If it is not, a boot parameter
is the cheap fix and I am happy to write it. Either answer is useful to
me, and I would rather be told it is a non-problem than guess.

Some context, offered as an explanation and not as an excuse. These
patches come out of running large models locally: I maintain a custom
kernel tree for my own inference workstation, and the changes in it
accumulated there first, against a real workload rather than as ideas. I
have started sending them upstream to put that pile in order and to find
out which of them are actually correct rather than merely useful to me.
This one is a fair sample of why that is worth doing, and of why the order
I did it in was wrong: I posted while still testing, instead of testing
and then posting. I am slowing the pace down and the rest stays local
until it has had more than this one got.

Thanks for the review. It caught a real error.

Ferran

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

[Lorenzo Stoakes (ARM)]

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 <ferran.duarri@me.com>

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

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

[Ferran Duarri]

Lorenzo, we crossed. Yours was 18:53, my withdrawal 19:10, so this isn't me
arguing back at it.

You're right, and so is David. These are patches I run on my own
workstation, they aren't settled yet, and I started posting them to put some
order on the pile. Wrong way round, and I can see that now.

On the process bit I should've got there myself. Coding assistant on the
changelog and on this thread, which generated-content.rst covers, and no
Assisted-by tag when there should have been one. Next ones will have it.
Reading both links now.

Patch is dead anyway, I had vma_thp_gfp_mask() backwards. That's in the
other mail.

Cheers,
Ferran

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

[Ferran]

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 <ferran.duarri@me.com>
> 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