[PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Cédric Le Goater]

From: Cedric Le Goater <clg@redhat.com>

The global THP sysfs policy (transparent_hugepage=never/madvise/always)
gates the huge fault dispatch path in __thp_vma_allowable_orders() for
all non-anonymous VMAs, including PFN-mapped device BARs (VM_PFNMAP).

DAX VMAs already bypass this check via an early return:

	if (vma_is_dax(vma))
		return in_pf ? orders : 0;

But "special huge" VMAs -- identified by vma_is_special_huge() -- do not
get this early return, even though they share the same fundamental
property: they map physical addresses directly into page tables and
involve no memory allocation, no compaction, no splitting, and no
reclaim. The THP policy has no meaningful effect on them.

This matters for VFIO PCI passthrough of large-BAR devices such as
NVIDIA H200 NVL GPUs (256 GB BAR each). The VFIO driver registers a
.huge_fault handler (vfio_pci_mmap_huge_fault) that dispatches to
vmf_insert_pfn_pmd/pud, and QEMU's vfio_region_mmap() aligns the BAR
mappings for huge page table entries. Both prerequisites are met, but
with THP=never or THP=madvise, __thp_vma_allowable_orders() returns 0
before reaching the "trust huge_fault handlers" code.

The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.

Configurations that trigger this:
  - transparent_hugepage=never on the kernel command line
  - The tuned cpu-partitioning profile (inherits network-latency, which
    sets transparent_hugepages=never via sysfs)
  - transparent_hugepage=madvise (the RHEL default), since VFIO VMAs
    lack VM_HUGEPAGE and QEMU does not call madvise(MADV_HUGEPAGE) on
    BAR mmap regions

Extend the existing DAX early return to also cover vma_is_special_huge()
VMAs. This is consistent with how vma_is_special_huge() is already
treated for supported_orders (grouped with DAX). The mm/Kconfig TODO
comment "Allow to be enabled without THP" also acknowledges this
coupling is wrong.

Cc: Peter Xu <peterx@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Zi Yan <ziy@nvidia.com>
Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cedric Le Goater <clg@redhat.com>
---
 mm/huge_memory.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 58cabe6af33d031e48250e21db51506bc46c97b2..6dfef5500a054f09f9ece6df8bf7a0194624350f 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -139,8 +139,12 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
 	if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags, forced_collapse))
 		return 0;
 
-	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
-	if (vma_is_dax(vma))
+	/*
+	 * khugepaged doesn't collapse DAX or special huge VMAs, but page
+	 * fault is fine. These map physical addresses directly — the THP
+	 * policy is irrelevant for them.
+	 */
+	if (vma_is_dax(vma) || vma_is_special_huge(vma))
 		return in_pf ? orders : 0;
 
 	/*
-- 
2.55.0

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Lorenzo Stoakes (ARM)]

On Wed, Aug 05, 2026 at 07:55:40AM +0200, Cédric Le Goater wrote:
> From: Cedric Le Goater <clg@redhat.com>
>
> The global THP sysfs policy (transparent_hugepage=never/madvise/always)
> gates the huge fault dispatch path in __thp_vma_allowable_orders() for
> all non-anonymous VMAs, including PFN-mapped device BARs (VM_PFNMAP).
>
> DAX VMAs already bypass this check via an early return:
>
> 	if (vma_is_dax(vma))
> 		return in_pf ? orders : 0;
>
> But "special huge" VMAs -- identified by vma_is_special_huge() -- do not
> get this early return, even though they share the same fundamental
> property: they map physical addresses directly into page tables and
> involve no memory allocation, no compaction, no splitting, and no
> reclaim. The THP policy has no meaningful effect on them.

Re: allocation that's not true - vma_is_special_huge() returns true
for !dax PFN/mixed maps, and mixed maps can absolutely have allocated
memory in them however obviously they are not rmappable, nor subject to THP
in the usual way).

In general I think this patch description is misleading.

Page faults are gated on the THP tunables on purpose with DAX being
specifically excluded because it's statically allocated.

So you're asking for a _policy_ change and it's far too broad - now you're
saying all PFN and mixed mappings (regardless of whether they implement
.huge_fault) should _ignore_ THP tunables, while citing one specific case.

It's in any case as specified seems far too wide.

So at the very least this should instead check .huge_fault.

But we are _explicitly_ disallowing .huge_fault page fault if the policy
doesn't enable it.

So really I think this should be instead - 'is PFN map and .huge_fault'.

But it shouldn't be done here, see below.

>
> This matters for VFIO PCI passthrough of large-BAR devices such as
> NVIDIA H200 NVL GPUs (256 GB BAR each). The VFIO driver registers a
> .huge_fault handler (vfio_pci_mmap_huge_fault) that dispatches to
> vmf_insert_pfn_pmd/pud, and QEMU's vfio_region_mmap() aligns the BAR
> mappings for huge page table entries. Both prerequisites are met, but
> with THP=never or THP=madvise, __thp_vma_allowable_orders() returns 0
> before reaching the "trust huge_fault handlers" code.

Yikes...

>
> The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.

Yeah but the users explicitly disable THP.

It is wonky that we have huge folio support and THP support... but
.huge_fault is explicitly a THP thing (at least for now).

But OTOH it seems the huge PFN map series should have addressed this.

>
> Configurations that trigger this:
>   - transparent_hugepage=never on the kernel command line
>   - The tuned cpu-partitioning profile (inherits network-latency, which
>     sets transparent_hugepages=never via sysfs)
>   - transparent_hugepage=madvise (the RHEL default), since VFIO VMAs
>     lack VM_HUGEPAGE and QEMU does not call madvise(MADV_HUGEPAGE) on
>     BAR mmap regions
>
> Extend the existing DAX early return to also cover vma_is_special_huge()
> VMAs. This is consistent with how vma_is_special_huge() is already
> treated for supported_orders (grouped with DAX). The mm/Kconfig TODO
> comment "Allow to be enabled without THP" also acknowledges this
> coupling is wrong.
>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Zi Yan <ziy@nvidia.com>
> Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4
> Signed-off-by: Cedric Le Goater <clg@redhat.com>
> ---
>  mm/huge_memory.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 58cabe6af33d031e48250e21db51506bc46c97b2..6dfef5500a054f09f9ece6df8bf7a0194624350f 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -139,8 +139,12 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>  	if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags, forced_collapse))
>  		return 0;
>
> -	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
> -	if (vma_is_dax(vma))
> +	/*
> +	 * khugepaged doesn't collapse DAX or special huge VMAs, but page
> +	 * fault is fine. These map physical addresses directly — the THP
> +	 * policy is irrelevant for them.
> +	 */
> +	if (vma_is_dax(vma) || vma_is_special_huge(vma))
>  		return in_pf ? orders : 0;

So yeah I think this is wrong.

As above it should be a narrower check. But also it breaks the smaps case
causing incorrect reporting  (!in_pf -> THPeligible: 0 for things that
are, in fact, THP-eligible).

It also eliminates the huge_fault check in the !vma_is_anonymous() branch
below this.

So I think it should be something more like the attached.

That way all the handling remains the same and the override is applied in
the right place plus smaps keeps working.

Cheers, Lorenzo

>
>  	/*
> --
> 2.55.0
>

----8<----
From d6537260722c8741586e6295c8eea68d06087efa Mon Sep 17 00:00:00 2001
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: Wed, 5 Aug 2026 11:35:13 +0100
Subject: [PATCH] ideas

---
 mm/huge_memory.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index abc65d608c23..5fa01364f089 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
 	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
 }

+static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
+					  bool forced_collapse)
+{
+	if (forced_collapse)
+		return false;
+	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
+	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
+	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
+		return false;
+	return true;
+}
+
+static bool can_thp_collapse_file(const struct vm_area_struct *vma,
+		vm_flags_t vm_flags, bool forced_collapse)
+{
+	/* Override THP tunables? */
+	if (!should_obey_thp_file_tunables(vma, forced_collapse))
+		return true;
+	/* THP=always? */
+	if (hugepage_global_always())
+		return true;
+	/* THP=madvise? */
+	if (!hugepage_global_enabled())
+		return false;
+	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
+	return vm_flags & VM_HUGEPAGE;
+}
+
 unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
 					 vm_flags_t vm_flags,
 					 enum tva_type type,
@@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
 		 * Enforce THP collapse requirements as necessary. Anonymous vmas
 		 * were already handled in thp_vma_allowable_orders().
 		 */
-		if (!forced_collapse &&
-		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
-						    !hugepage_global_always())))
+		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
 			return 0;

 		/*
--
2.55.0

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Cédric Le Goater]

Thanks for the quick feedback Lorenzo !
> So I think it should be something more like the attached.
> 
> That way all the handling remains the same and the override is applied in
> the right place plus smaps keeps working.

LGTM, do you want me to respin a v2 with what's below ? or you'd rather
send it yourself.

C.



> ----8<----
>  From d6537260722c8741586e6295c8eea68d06087efa Mon Sep 17 00:00:00 2001
> From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
> Date: Wed, 5 Aug 2026 11:35:13 +0100
> Subject: [PATCH] ideas
> 
> ---
>   mm/huge_memory.c | 32 +++++++++++++++++++++++++++++---
>   1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index abc65d608c23..5fa01364f089 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
>   	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
>   }
> 
> +static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
> +					  bool forced_collapse)
> +{
> +	if (forced_collapse)
> +		return false;
> +	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
> +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
> +	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
> +		return false;
> +	return true;
> +}
> +
> +static bool can_thp_collapse_file(const struct vm_area_struct *vma,
> +		vm_flags_t vm_flags, bool forced_collapse)
> +{
> +	/* Override THP tunables? */
> +	if (!should_obey_thp_file_tunables(vma, forced_collapse))
> +		return true;
> +	/* THP=always? */
> +	if (hugepage_global_always())
> +		return true;
> +	/* THP=madvise? */
> +	if (!hugepage_global_enabled())
> +		return false;
> +	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
> +	return vm_flags & VM_HUGEPAGE;
> +}
> +
>   unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>   					 vm_flags_t vm_flags,
>   					 enum tva_type type,
> @@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>   		 * Enforce THP collapse requirements as necessary. Anonymous vmas
>   		 * were already handled in thp_vma_allowable_orders().
>   		 */
> -		if (!forced_collapse &&
> -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
> -						    !hugepage_global_always())))
> +		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
>   			return 0;
> 
>   		/*
> --
> 2.55.0
> 

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Lorenzo Stoakes (ARM)]

On Wed, Aug 05, 2026 at 06:21:30PM +0200, Cédric Le Goater wrote:
> Thanks for the quick feedback Lorenzo !
> > So I think it should be something more like the attached.
> >
> > That way all the handling remains the same and the override is applied in
> > the right place plus smaps keeps working.
>
> LGTM, do you want me to respin a v2 with what's below ? or you'd rather
> send it yourself.

Thanks, I think as it's somewhat divergent maybe better if I send it with
Reported-by/Closes if that makes sense to you?

I'd like to get David's input on it first however!

>
> C.
>
>
>
> > ----8<----
> >  From d6537260722c8741586e6295c8eea68d06087efa Mon Sep 17 00:00:00 2001
> > From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
> > Date: Wed, 5 Aug 2026 11:35:13 +0100
> > Subject: [PATCH] ideas
> >
> > ---
> >   mm/huge_memory.c | 32 +++++++++++++++++++++++++++++---
> >   1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index abc65d608c23..5fa01364f089 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
> >   	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
> >   }
> >
> > +static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
> > +					  bool forced_collapse)
> > +{
> > +	if (forced_collapse)
> > +		return false;
> > +	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
> > +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
> > +	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
> > +		return false;
> > +	return true;
> > +}
> > +
> > +static bool can_thp_collapse_file(const struct vm_area_struct *vma,
> > +		vm_flags_t vm_flags, bool forced_collapse)
> > +{
> > +	/* Override THP tunables? */
> > +	if (!should_obey_thp_file_tunables(vma, forced_collapse))
> > +		return true;
> > +	/* THP=always? */
> > +	if (hugepage_global_always())
> > +		return true;
> > +	/* THP=madvise? */
> > +	if (!hugepage_global_enabled())
> > +		return false;
> > +	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
> > +	return vm_flags & VM_HUGEPAGE;
> > +}
> > +
> >   unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >   					 vm_flags_t vm_flags,
> >   					 enum tva_type type,
> > @@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >   		 * Enforce THP collapse requirements as necessary. Anonymous vmas
> >   		 * were already handled in thp_vma_allowable_orders().
> >   		 */
> > -		if (!forced_collapse &&
> > -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
> > -						    !hugepage_global_always())))
> > +		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
> >   			return 0;
> >
> >   		/*
> > --
> > 2.55.0
> >
>

--
Cheers, Lorenzo

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Cédric Le Goater]

On 8/5/26 18:26, Lorenzo Stoakes (ARM) wrote:
> On Wed, Aug 05, 2026 at 06:21:30PM +0200, Cédric Le Goater wrote:
>> Thanks for the quick feedback Lorenzo !
>>> So I think it should be something more like the attached.
>>>
>>> That way all the handling remains the same and the override is applied in
>>> the right place plus smaps keeps working.
>>
>> LGTM, do you want me to respin a v2 with what's below ? or you'd rather
>> send it yourself.
> 
> Thanks, I think as it's somewhat divergent maybe better if I send it with
> Reported-by/Closes if that makes sense to you?

Of course,
  
> I'd like to get David's input on it first however!

Yep.

Thanks,

C.

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Matthew Wilcox]

On Wed, Aug 05, 2026 at 11:41:46AM +0100, Lorenzo Stoakes (ARM) wrote:
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index abc65d608c23..5fa01364f089 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
>  	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
>  }
> 
> +static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
> +					  bool forced_collapse)
> +{
> +	if (forced_collapse)
> +		return false;
> +	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
> +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
> +	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
> +		return false;
> +	return true;
> +}
> +
> +static bool can_thp_collapse_file(const struct vm_area_struct *vma,
> +		vm_flags_t vm_flags, bool forced_collapse)
> +{
> +	/* Override THP tunables? */
> +	if (!should_obey_thp_file_tunables(vma, forced_collapse))
> +		return true;
> +	/* THP=always? */
> +	if (hugepage_global_always())
> +		return true;
> +	/* THP=madvise? */
> +	if (!hugepage_global_enabled())
> +		return false;
> +	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
> +	return vm_flags & VM_HUGEPAGE;
> +}
> +
>  unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>  					 vm_flags_t vm_flags,
>  					 enum tva_type type,
> @@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>  		 * Enforce THP collapse requirements as necessary. Anonymous vmas
>  		 * were already handled in thp_vma_allowable_orders().
>  		 */
> -		if (!forced_collapse &&
> -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
> -						    !hugepage_global_always())))
> +		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
>  			return 0;
> 
>  		/*

I think 'thp_' in all of this is confusing.  DAX isn't THPs.  PFNMAPs
aren't THPa.  There's other reasons to implement huge_fault that aren't
THPs.  Can we rename all of this to drop the 'thp_' string, starting
with thp_vma_allowable_order()?

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Lorenzo Stoakes (ARM)]

On Thu, Aug 06, 2026 at 02:44:10AM +0100, Matthew Wilcox wrote:
> On Wed, Aug 05, 2026 at 11:41:46AM +0100, Lorenzo Stoakes (ARM) wrote:
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index abc65d608c23..5fa01364f089 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
> >  	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
> >  }
> >
> > +static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
> > +					  bool forced_collapse)
> > +{
> > +	if (forced_collapse)
> > +		return false;
> > +	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
> > +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
> > +	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
> > +		return false;
> > +	return true;
> > +}
> > +
> > +static bool can_thp_collapse_file(const struct vm_area_struct *vma,
> > +		vm_flags_t vm_flags, bool forced_collapse)
> > +{
> > +	/* Override THP tunables? */
> > +	if (!should_obey_thp_file_tunables(vma, forced_collapse))
> > +		return true;
> > +	/* THP=always? */
> > +	if (hugepage_global_always())
> > +		return true;
> > +	/* THP=madvise? */
> > +	if (!hugepage_global_enabled())
> > +		return false;
> > +	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
> > +	return vm_flags & VM_HUGEPAGE;
> > +}
> > +
> >  unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >  					 vm_flags_t vm_flags,
> >  					 enum tva_type type,
> > @@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >  		 * Enforce THP collapse requirements as necessary. Anonymous vmas
> >  		 * were already handled in thp_vma_allowable_orders().
> >  		 */
> > -		if (!forced_collapse &&
> > -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
> > -						    !hugepage_global_always())))
> > +		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
> >  			return 0;
> >
> >  		/*
>
> I think 'thp_' in all of this is confusing.  DAX isn't THPs.  PFNMAPs
> aren't THPa.  There's other reasons to implement huge_fault that aren't
> THPs.  Can we rename all of this to drop the 'thp_' string, starting
> with thp_vma_allowable_order()?

Matthew, are you baiting the churnmeister 3000 into a refactor here? :)

I despise this function and agree with you entirely.

So maybe I could add a few other patches first before the change to improve
the horror show that is this function and its auxiliaries also :)

--
Cheers, Lorenzo

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[David Hildenbrand (Arm)]

> From d6537260722c8741586e6295c8eea68d06087efa Mon Sep 17 00:00:00 2001
> From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
> Date: Wed, 5 Aug 2026 11:35:13 +0100
> Subject: [PATCH] ideas
> 
> ---
>  mm/huge_memory.c | 32 +++++++++++++++++++++++++++++---
>  1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index abc65d608c23..5fa01364f089 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
>  	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
>  }
> 
> +static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
> +					  bool forced_collapse)
> +{> +	if (forced_collapse)
> +		return false;
> +	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
> +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
> +	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
> +		return false;
> +	return true;
> +}

If that's sufficient, then this is is the better direction.

> +> +static bool can_thp_collapse_file(const struct vm_area_struct *vma,
> +		vm_flags_t vm_flags, bool forced_collapse)
> +{
> +	/* Override THP tunables? */
> +	if (!should_obey_thp_file_tunables(vma, forced_collapse))
> +		return true;
> +	/* THP=always? */
> +	if (hugepage_global_always())
> +		return true;
> +	/* THP=madvise? */
> +	if (!hugepage_global_enabled())
> +		return false;
> +	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
> +	return vm_flags & VM_HUGEPAGE;
> +}
> +
>  unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>  					 vm_flags_t vm_flags,
>  					 enum tva_type type,
> @@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>  		 * Enforce THP collapse requirements as necessary. Anonymous vmas
>  		 * were already handled in thp_vma_allowable_orders().
>  		 */
> -		if (!forced_collapse &&
> -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
> -						    !hugepage_global_always())))
> +		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
>  			return 0;

I played a bit with that and came up with the following. Not quite happy about
it, just for your inspiration on naming and what to split out.

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a00df56a68b57..8ba77608959d4 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -111,6 +111,54 @@ static bool vma_is_special_huge(const struct vm_area_struct
*vma)
 	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
 }

+static bool file_vma_honors_thp_toggles(struct vm_area_struct *vma,
+		enum tva_type type)
+{
+	const bool forced_collapse = type == TVA_FORCED_COLLAPSE;
+
+	if (forced_collapse)
+		return false;
+	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
+	return !(vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault);
+}
+
+static bool vma_thp_toggles_enabled(struct vm_area_struct *vma,
+		vm_flags_t vm_flags)
+{
+	/* THP=always? */
+	if (hugepage_global_always())
+		return true;
+	/* THP=madvise and actually advised? */
+	return hugepage_global_enabled() && vm_flags & VM_HUGEPAGE;
+}
+
+static bool file_vma_forces_order_0(struct vm_area_struct *vma,
+		vm_flags_t vm_flags, enum tva_type type)
+{
+	const bool in_pf = type == TVA_PAGEFAULT;
+	const bool smaps = type == TVA_SMAPS;
+
+	/*
+	 * Enforce THP collapse requirements as necessary. Anonymous vmas
+	 * were already handled in thp_vma_allowable_orders().
+	 */
+
+	if (file_vma_honors_thp_toggles(vma, type) &&
+	    !vma_thp_toggles_enabled(vma, vm_flags))
+		return true;
+
+	/*
+	 * Trust that ->huge_fault() handlers know what they are doing
+	 * in fault path.
+	 */
+	if (((in_pf || smaps)) && vma->vm_ops->huge_fault)
+		return false;
+	/* Only regular file is valid in collapse path */
+	if (((!in_pf || smaps)) && file_thp_enabled(vma))
+		return false;
+	return true;
+}
+
 unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
 					 vm_flags_t vm_flags,
 					 enum tva_type type,
@@ -183,27 +231,8 @@ unsigned long __thp_vma_allowable_orders(struct
vm_area_struct *vma,
 						   vma, vma_start_pgoff(vma), 0,
 						   forced_collapse);

-	if (!vma_is_anonymous(vma)) {
-		/*
-		 * Enforce THP collapse requirements as necessary. Anonymous vmas
-		 * were already handled in thp_vma_allowable_orders().
-		 */
-		if (!forced_collapse &&
-		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
-						    !hugepage_global_always())))
-			return 0;
-
-		/*
-		 * Trust that ->huge_fault() handlers know what they are doing
-		 * in fault path.
-		 */
-		if (((in_pf || smaps)) && vma->vm_ops->huge_fault)
-			return orders;
-		/* Only regular file is valid in collapse path */
-		if (((!in_pf || smaps)) && file_thp_enabled(vma))
-			return orders;
-		return 0;
-	}
+	if (!vma_is_anonymous(vma))
+		return __file_vma_forces_order_0(vma, vm_flags, type) ? 0 : orders;

 	if (vma_is_temporary_stack(vma))
 		return 0;

-- 
Cheers,

David

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Cédric Le Goater]

On 8/6/26 18:19, David Hildenbrand (Arm) wrote:
>>  From d6537260722c8741586e6295c8eea68d06087efa Mon Sep 17 00:00:00 2001
>> From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
>> Date: Wed, 5 Aug 2026 11:35:13 +0100
>> Subject: [PATCH] ideas
>>
>> ---
>>   mm/huge_memory.c | 32 +++++++++++++++++++++++++++++---
>>   1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index abc65d608c23..5fa01364f089 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -111,6 +111,34 @@ static bool vma_is_special_huge(const struct vm_area_struct *vma)
>>   	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
>>   }
>>
>> +static bool should_obey_thp_file_tunables(const struct vm_area_struct *vma,
>> +					  bool forced_collapse)
>> +{> +	if (forced_collapse)
>> +		return false;
>> +	VM_WARN_ON_ONCE(vma_is_anonymous(vma));
>> +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */
>> +	if (vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault)
>> +		return false;
>> +	return true;
>> +}
> 
> If that's sufficient, then this is is the better direction.
> 
>> +> +static bool can_thp_collapse_file(const struct vm_area_struct *vma,
>> +		vm_flags_t vm_flags, bool forced_collapse)
>> +{
>> +	/* Override THP tunables? */
>> +	if (!should_obey_thp_file_tunables(vma, forced_collapse))
>> +		return true;
>> +	/* THP=always? */
>> +	if (hugepage_global_always())
>> +		return true;
>> +	/* THP=madvise? */
>> +	if (!hugepage_global_enabled())
>> +		return false;
>> +	/* Has VMA had madvise(..., MADV_HUGEPAGE) applied to it? */
>> +	return vm_flags & VM_HUGEPAGE;
>> +}
>> +
>>   unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>>   					 vm_flags_t vm_flags,
>>   					 enum tva_type type,
>> @@ -188,9 +216,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>>   		 * Enforce THP collapse requirements as necessary. Anonymous vmas
>>   		 * were already handled in thp_vma_allowable_orders().
>>   		 */
>> -		if (!forced_collapse &&
>> -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
>> -						    !hugepage_global_always())))
>> +		if (!can_thp_collapse_file(vma, vm_flags, forced_collapse))
>>   			return 0;
> 
> I played a bit with that and came up with the following. Not quite happy about
> it, just for your inspiration on naming and what to split out.
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index a00df56a68b57..8ba77608959d4 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -111,6 +111,54 @@ static bool vma_is_special_huge(const struct vm_area_struct
> *vma)
>   	return vma_test_any(vma, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT);
>   }
> 
> +static bool file_vma_honors_thp_toggles(struct vm_area_struct *vma,> +		enum tva_type type)
> +{
> +	const bool forced_collapse = type == TVA_FORCED_COLLAPSE;
> +
> +	if (forced_collapse)
> +		return false;
> +	/* Huge PFN mappings allocate no folios so the policy doesn't apply. */

So, may be rename the routine to file_vma_thp_policy_applies() ?

> +	return !(vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault);
> +}
> +
> +static bool vma_thp_toggles_enabled(struct vm_area_struct *vma,

This routine could use the same 'file_vma_' prefix.

> +		vm_flags_t vm_flags)
> +{
> +	/* THP=always? */
> +	if (hugepage_global_always())
> +		return true;
> +	/* THP=madvise and actually advised? */
> +	return hugepage_global_enabled() && vm_flags & VM_HUGEPAGE;

I would add extra parentheses around 'vm_flags & VM_HUGEPAGE'

> +}
> +
> +static bool file_vma_forces_order_0(struct vm_area_struct *vma,
> +		vm_flags_t vm_flags, enum tva_type type)
> +{
> +	const bool in_pf = type == TVA_PAGEFAULT;
> +	const bool smaps = type == TVA_SMAPS;
> +
> +	/*
> +	 * Enforce THP collapse requirements as necessary. Anonymous vmas
> +	 * were already handled in thp_vma_allowable_orders().
> +	 */
> +
> +	if (file_vma_honors_thp_toggles(vma, type) &&
> +	    !vma_thp_toggles_enabled(vma, vm_flags))
> +		return true;
> +
> +	/*
> +	 * Trust that ->huge_fault() handlers know what they are doing
> +	 * in fault path.
> +	 */
> +	if (((in_pf || smaps)) && vma->vm_ops->huge_fault)

and there remove the extra parentheses.

> +		return false;
> +	/* Only regular file is valid in collapse path */
> +	if (((!in_pf || smaps)) && file_thp_enabled(vma))

there too.

Thanks,

C.

> +		return false;
> +	return true;
> +}
> +
>   unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>   					 vm_flags_t vm_flags,
>   					 enum tva_type type,
> @@ -183,27 +231,8 @@ unsigned long __thp_vma_allowable_orders(struct
> vm_area_struct *vma,
>   						   vma, vma_start_pgoff(vma), 0,
>   						   forced_collapse);
> 
> -	if (!vma_is_anonymous(vma)) {
> -		/*
> -		 * Enforce THP collapse requirements as necessary. Anonymous vmas
> -		 * were already handled in thp_vma_allowable_orders().
> -		 */
> -		if (!forced_collapse &&
> -		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
> -						    !hugepage_global_always())))
> -			return 0;
> -
> -		/*
> -		 * Trust that ->huge_fault() handlers know what they are doing
> -		 * in fault path.
> -		 */
> -		if (((in_pf || smaps)) && vma->vm_ops->huge_fault)
> -			return orders;
> -		/* Only regular file is valid in collapse path */
> -		if (((!in_pf || smaps)) && file_thp_enabled(vma))
> -			return orders;
> -		return 0;
> -	}
> +	if (!vma_is_anonymous(vma))
> +		return __file_vma_forces_order_0(vma, vm_flags, type) ? 0 : orders;
> 
>   	if (vma_is_temporary_stack(vma))
>   		return 0;
> 

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[David Hildenbrand (Arm)]

>>
>> +static bool file_vma_honors_thp_toggles(struct vm_area_struct *vma,> +       
>> enum tva_type type)
>> +{
>> +    const bool forced_collapse = type == TVA_FORCED_COLLAPSE;
>> +
>> +    if (forced_collapse)
>> +        return false;
>> +    /* Huge PFN mappings allocate no folios so the policy doesn't apply. */
> 
> So, may be rename the routine to file_vma_thp_policy_applies() ?

Also a possibility. I'll let Lorenzo handle this.

> 
>> +    return !(vma_test(vma, VMA_PFNMAP_BIT) && vma->vm_ops->huge_fault);
>> +}
>> +
>> +static bool vma_thp_toggles_enabled(struct vm_area_struct *vma,
> 
> This routine could use the same 'file_vma_' prefix.

It's true even for non-file vmas.

> 
>> +        vm_flags_t vm_flags)
>> +{
>> +    /* THP=always? */
>> +    if (hugepage_global_always())
>> +        return true;
>> +    /* THP=madvise and actually advised? */
>> +    return hugepage_global_enabled() && vm_flags & VM_HUGEPAGE;
> 
> I would add extra parentheses around 'vm_flags & VM_HUGEPAGE'

It's even required and the compiler might complain :)

> 
>> +}
>> +
>> +static bool file_vma_forces_order_0(struct vm_area_struct *vma,
>> +        vm_flags_t vm_flags, enum tva_type type)
>> +{
>> +    const bool in_pf = type == TVA_PAGEFAULT;
>> +    const bool smaps = type == TVA_SMAPS;
>> +
>> +    /*
>> +     * Enforce THP collapse requirements as necessary. Anonymous vmas
>> +     * were already handled in thp_vma_allowable_orders().
>> +     */
>> +
>> +    if (file_vma_honors_thp_toggles(vma, type) &&
>> +        !vma_thp_toggles_enabled(vma, vm_flags))
>> +        return true;
>> +
>> +    /*
>> +     * Trust that ->huge_fault() handlers know what they are doing
>> +     * in fault path.
>> +     */
>> +    if (((in_pf || smaps)) && vma->vm_ops->huge_fault)
> 
> and there remove the extra parentheses.

Agreed, that was already there in existing code.

Anyhow, it was mostly for inspiration for Lorenzo. I should start spelling out
more clearly in the future that this is just a quick prototype, because recently
people assumed that some quick stuff I post inline would be complete or even
tested :)

-- 
Cheers,

David

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Jason Gunthorpe]

On Wed, Aug 05, 2026 at 07:55:40AM +0200, Cédric Le Goater wrote:

> The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.

Broadly upstream we expect people to use iommufd and dmabuf for these
configurations to avoid all this nonsense overhead. :\

Jason

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Lorenzo Stoakes (ARM)]

On Wed, Aug 05, 2026 at 09:15:24AM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 05, 2026 at 07:55:40AM +0200, Cédric Le Goater wrote:
>
> > The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> > page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> > with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> > severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.
>
> Broadly upstream we expect people to use iommufd and dmabuf for these
> configurations to avoid all this nonsense overhead. :\

Point taken on that :) but I think it's generally reasonable in line with the
huge PFN map changes to do something like I suggested.

>
> Jason

--
Cheers, Lorenzo

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Jason Gunthorpe]

On Wed, Aug 05, 2026 at 05:29:34PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Wed, Aug 05, 2026 at 09:15:24AM -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 05, 2026 at 07:55:40AM +0200, Cédric Le Goater wrote:
> >
> > > The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> > > page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> > > with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> > > severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.
> >
> > Broadly upstream we expect people to use iommufd and dmabuf for these
> > configurations to avoid all this nonsense overhead. :\
> 
> Point taken on that :) but I think it's generally reasonable in line with the
> huge PFN map changes to do something like I suggested.

Yeah, for cases like this working with pure PFNs from some non-folio
source the size should be entirely delegated to the driver, and driver
should always have the opportunity to place a maximally sized PTE.

It is definately wrong to intermix it with any THP logic. DAX isn't a
special case, it was just the first place to partially implement
something that looks like this.

Jason

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Lorenzo Stoakes (ARM)]

On Wed, Aug 05, 2026 at 01:52:40PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 05, 2026 at 05:29:34PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Wed, Aug 05, 2026 at 09:15:24AM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 05, 2026 at 07:55:40AM +0200, Cédric Le Goater wrote:
> > >
> > > > The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> > > > page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> > > > with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> > > > severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.
> > >
> > > Broadly upstream we expect people to use iommufd and dmabuf for these
> > > configurations to avoid all this nonsense overhead. :\
> >
> > Point taken on that :) but I think it's generally reasonable in line with the
> > huge PFN map changes to do something like I suggested.
>
> Yeah, for cases like this working with pure PFNs from some non-folio
> source the size should be entirely delegated to the driver, and driver
> should always have the opportunity to place a maximally sized PTE.
>
> It is definately wrong to intermix it with any THP logic. DAX isn't a
> special case, it was just the first place to partially implement
> something that looks like this.

Might actually be worth getting rid of this dumb DAX special case and putting it
in the new thing too actually so it's actually normalised as 'statically mapped
stuff that doesn't allocate isn't gated on THP tunables' alongside huge PFN.

>
> Jason

--
Cheers, Lorenzo

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[David Hildenbrand (Arm)]

On 8/5/26 07:55, Cédric Le Goater wrote:
> From: Cedric Le Goater <clg@redhat.com>
> 
> The global THP sysfs policy (transparent_hugepage=never/madvise/always)
> gates the huge fault dispatch path in __thp_vma_allowable_orders() for
> all non-anonymous VMAs, including PFN-mapped device BARs (VM_PFNMAP).
> 
> DAX VMAs already bypass this check via an early return:
> 
> 	if (vma_is_dax(vma))
> 		return in_pf ? orders : 0;
> 
> But "special huge" VMAs -- identified by vma_is_special_huge() -- do not
> get this early return, even though they share the same fundamental
> property: they map physical addresses directly into page tables and
> involve no memory allocation, no compaction, no splitting, and no
> reclaim. The THP policy has no meaningful effect on them.
> 
> This matters for VFIO PCI passthrough of large-BAR devices such as
> NVIDIA H200 NVL GPUs (256 GB BAR each). The VFIO driver registers a
> .huge_fault handler (vfio_pci_mmap_huge_fault) that dispatches to
> vmf_insert_pfn_pmd/pud, and QEMU's vfio_region_mmap() aligns the BAR
> mappings for huge page table entries. Both prerequisites are met, but
> with THP=never or THP=madvise, __thp_vma_allowable_orders() returns 0
> before reaching the "trust huge_fault handlers" code.
> 
> The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.
> 
> Configurations that trigger this:
>   - transparent_hugepage=never on the kernel command line
>   - The tuned cpu-partitioning profile (inherits network-latency, which
>     sets transparent_hugepages=never via sysfs)
>   - transparent_hugepage=madvise (the RHEL default), since VFIO VMAs
>     lack VM_HUGEPAGE and QEMU does not call madvise(MADV_HUGEPAGE) on
>     BAR mmap regions
> 
> Extend the existing DAX early return to also cover vma_is_special_huge()
> VMAs. This is consistent with how vma_is_special_huge() is already
> treated for supported_orders (grouped with DAX). The mm/Kconfig TODO
> comment "Allow to be enabled without THP" also acknowledges this
> coupling is wrong.
> 
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Zi Yan <ziy@nvidia.com>
> Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4
> Signed-off-by: Cedric Le Goater <clg@redhat.com>
> ---
>  mm/huge_memory.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 58cabe6af33d031e48250e21db51506bc46c97b2..6dfef5500a054f09f9ece6df8bf7a0194624350f 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -139,8 +139,12 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>  	if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags, forced_collapse))
>  		return 0;
>  
> -	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
> -	if (vma_is_dax(vma))
> +	/*
> +	 * khugepaged doesn't collapse DAX or special huge VMAs, but page
> +	 * fault is fine. These map physical addresses directly — the THP
> +	 * policy is irrelevant for them.

emdash in a code comment?

Then I spot

	Assisted-by: Claude:claude-opus-4

and really have to shake my head.

-- 
Cheers,

David

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Lorenzo Stoakes (ARM)]

On Thu, Aug 06, 2026 at 04:26:20PM +0200, David Hildenbrand (Arm) wrote:
> On 8/5/26 07:55, Cédric Le Goater wrote:
> > From: Cedric Le Goater <clg@redhat.com>
> >
> > The global THP sysfs policy (transparent_hugepage=never/madvise/always)
> > gates the huge fault dispatch path in __thp_vma_allowable_orders() for
> > all non-anonymous VMAs, including PFN-mapped device BARs (VM_PFNMAP).
> >
> > DAX VMAs already bypass this check via an early return:
> >
> > 	if (vma_is_dax(vma))
> > 		return in_pf ? orders : 0;
> >
> > But "special huge" VMAs -- identified by vma_is_special_huge() -- do not
> > get this early return, even though they share the same fundamental
> > property: they map physical addresses directly into page tables and
> > involve no memory allocation, no compaction, no splitting, and no
> > reclaim. The THP policy has no meaningful effect on them.
> >
> > This matters for VFIO PCI passthrough of large-BAR devices such as
> > NVIDIA H200 NVL GPUs (256 GB BAR each). The VFIO driver registers a
> > .huge_fault handler (vfio_pci_mmap_huge_fault) that dispatches to
> > vmf_insert_pfn_pmd/pud, and QEMU's vfio_region_mmap() aligns the BAR
> > mappings for huge page table entries. Both prerequisites are met, but
> > with THP=never or THP=madvise, __thp_vma_allowable_orders() returns 0
> > before reaching the "trust huge_fault handlers" code.
> >
> > The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> > page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> > with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> > severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.
> >
> > Configurations that trigger this:
> >   - transparent_hugepage=never on the kernel command line
> >   - The tuned cpu-partitioning profile (inherits network-latency, which
> >     sets transparent_hugepages=never via sysfs)
> >   - transparent_hugepage=madvise (the RHEL default), since VFIO VMAs
> >     lack VM_HUGEPAGE and QEMU does not call madvise(MADV_HUGEPAGE) on
> >     BAR mmap regions
> >
> > Extend the existing DAX early return to also cover vma_is_special_huge()
> > VMAs. This is consistent with how vma_is_special_huge() is already
> > treated for supported_orders (grouped with DAX). The mm/Kconfig TODO
> > comment "Allow to be enabled without THP" also acknowledges this
> > coupling is wrong.
> >
> > Cc: Peter Xu <peterx@redhat.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Lorenzo Stoakes <ljs@kernel.org>
> > Cc: David Hildenbrand <david@kernel.org>
> > Cc: Alex Williamson <alex.williamson@redhat.com>
> > Cc: Jason Gunthorpe <jgg@nvidia.com>
> > Cc: Zi Yan <ziy@nvidia.com>
> > Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs")
> > Cc: stable@vger.kernel.org
> > Assisted-by: Claude:claude-opus-4
> > Signed-off-by: Cedric Le Goater <clg@redhat.com>
> > ---
> >  mm/huge_memory.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 58cabe6af33d031e48250e21db51506bc46c97b2..6dfef5500a054f09f9ece6df8bf7a0194624350f 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -139,8 +139,12 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
> >  	if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags, forced_collapse))
> >  		return 0;
> >
> > -	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
> > -	if (vma_is_dax(vma))
> > +	/*
> > +	 * khugepaged doesn't collapse DAX or special huge VMAs, but page
> > +	 * fault is fine. These map physical addresses directly — the THP
> > +	 * policy is irrelevant for them.
>
> emdash in a code comment?
>
> Then I spot
>
> 	Assisted-by: Claude:claude-opus-4
>
> and really have to shake my head.

Ha, I missed that!

Well all the more reason for me to take over this patch... :)

At least the AI is acked here (appreciate that at least Cedric).

I think the _actual issue_ is valid at least. The huge pfn stuff did seem to
completely miss this aspect of things.

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Cédric Le Goater]

On 8/6/26 16:28, Lorenzo Stoakes (ARM) wrote:
> On Thu, Aug 06, 2026 at 04:26:20PM +0200, David Hildenbrand (Arm) wrote:
>> On 8/5/26 07:55, Cédric Le Goater wrote:
>>> From: Cedric Le Goater <clg@redhat.com>
>>>
>>> The global THP sysfs policy (transparent_hugepage=never/madvise/always)
>>> gates the huge fault dispatch path in __thp_vma_allowable_orders() for
>>> all non-anonymous VMAs, including PFN-mapped device BARs (VM_PFNMAP).
>>>
>>> DAX VMAs already bypass this check via an early return:
>>>
>>> 	if (vma_is_dax(vma))
>>> 		return in_pf ? orders : 0;
>>>
>>> But "special huge" VMAs -- identified by vma_is_special_huge() -- do not
>>> get this early return, even though they share the same fundamental
>>> property: they map physical addresses directly into page tables and
>>> involve no memory allocation, no compaction, no splitting, and no
>>> reclaim. The THP policy has no meaningful effect on them.
>>>
>>> This matters for VFIO PCI passthrough of large-BAR devices such as
>>> NVIDIA H200 NVL GPUs (256 GB BAR each). The VFIO driver registers a
>>> .huge_fault handler (vfio_pci_mmap_huge_fault) that dispatches to
>>> vmf_insert_pfn_pmd/pud, and QEMU's vfio_region_mmap() aligns the BAR
>>> mappings for huge page table entries. Both prerequisites are met, but
>>> with THP=never or THP=madvise, __thp_vma_allowable_orders() returns 0
>>> before reaching the "trust huge_fault handlers" code.
>>>
>>> The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
>>> page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
>>> with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
>>> severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.
>>>
>>> Configurations that trigger this:
>>>    - transparent_hugepage=never on the kernel command line
>>>    - The tuned cpu-partitioning profile (inherits network-latency, which
>>>      sets transparent_hugepages=never via sysfs)
>>>    - transparent_hugepage=madvise (the RHEL default), since VFIO VMAs
>>>      lack VM_HUGEPAGE and QEMU does not call madvise(MADV_HUGEPAGE) on
>>>      BAR mmap regions
>>>
>>> Extend the existing DAX early return to also cover vma_is_special_huge()
>>> VMAs. This is consistent with how vma_is_special_huge() is already
>>> treated for supported_orders (grouped with DAX). The mm/Kconfig TODO
>>> comment "Allow to be enabled without THP" also acknowledges this
>>> coupling is wrong.
>>>
>>> Cc: Peter Xu <peterx@redhat.com>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Cc: Lorenzo Stoakes <ljs@kernel.org>
>>> Cc: David Hildenbrand <david@kernel.org>
>>> Cc: Alex Williamson <alex.williamson@redhat.com>
>>> Cc: Jason Gunthorpe <jgg@nvidia.com>
>>> Cc: Zi Yan <ziy@nvidia.com>
>>> Fixes: 5dd40721f147 ("mm: allow THP orders for PFNMAPs")
>>> Cc: stable@vger.kernel.org
>>> Assisted-by: Claude:claude-opus-4
>>> Signed-off-by: Cedric Le Goater <clg@redhat.com>
>>> ---
>>>   mm/huge_memory.c | 8 ++++++--
>>>   1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 58cabe6af33d031e48250e21db51506bc46c97b2..6dfef5500a054f09f9ece6df8bf7a0194624350f 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -139,8 +139,12 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>>>   	if (thp_disabled_by_hw() || vma_thp_disabled(vma, vm_flags, forced_collapse))
>>>   		return 0;
>>>
>>> -	/* khugepaged doesn't collapse DAX vma, but page fault is fine. */
>>> -	if (vma_is_dax(vma))
>>> +	/*
>>> +	 * khugepaged doesn't collapse DAX or special huge VMAs, but page
>>> +	 * fault is fine. These map physical addresses directly — the THP
>>> +	 * policy is irrelevant for them.
>>
>> emdash in a code comment?

There are quite a few of these in the code in fact.

>> Then I spot
>>
>> 	Assisted-by: Claude:claude-opus-4
>>
>> and really have to shake my head.

It's a one liner. Good enough to raise the discussion no ?

> Ha, I missed that!

Me too. But, you have more to add to it anyway. It should be dropped.

> Well all the more reason for me to take over this patch... :)
> 
> At least the AI is acked here (appreciate that at least Cedric).

Yeah. Let's be honest. Even if I understand what is going on, Claude was
faster at digging through the code and connecting the dots than I would
have been on my own.

The AI behemoth dropped my accent though. Cédric it should have been.
I wonder why.

> I think the _actual issue_ is valid at least. The huge pfn stuff did seem to
> completely miss this aspect of things.

It's a real problem indeed and to cover mix of workloads, it it difficult
to address without a kernel patch.

Cheers,

C.

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[David Hildenbrand (Arm)]

On 8/6/26 16:42, Cédric Le Goater wrote:
> On 8/6/26 16:28, Lorenzo Stoakes (ARM) wrote:
>> On Thu, Aug 06, 2026 at 04:26:20PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> emdash in a code comment?
> 
> There are quite a few of these in the code in fact.
> 
>>> Then I spot
>>>
>>>     Assisted-by: Claude:claude-opus-4
>>>
>>> and really have to shake my head.
> 
> It's a one liner. Good enough to raise the discussion no ?

Just to be clear: Unchecked AI slop in any form is making my life worse every day.

-- 
Cheers,

David

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Cédric Le Goater]

On 8/6/26 16:47, David Hildenbrand (Arm) wrote:
> On 8/6/26 16:42, Cédric Le Goater wrote:
>> On 8/6/26 16:28, Lorenzo Stoakes (ARM) wrote:
>>> On Thu, Aug 06, 2026 at 04:26:20PM +0200, David Hildenbrand (Arm) wrote:
>>>>
>>>> emdash in a code comment?
>>
>> There are quite a few of these in the code in fact.
>>
>>>> Then I spot
>>>>
>>>>      Assisted-by: Claude:claude-opus-4
>>>>
>>>> and really have to shake my head.
>>
>> It's a one liner. Good enough to raise the discussion no ?
> 
> Just to be clear: Unchecked AI slop in any form is making my life worse every day.
> 

Point taken. This is not the case here. There is quite a lot of work
behind this from several people on the analysis. Lorenzo is taking over
to address it cleanly.

Thanks,

C.

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[David Hildenbrand (Arm)]

On 8/6/26 16:53, Cédric Le Goater wrote:
> On 8/6/26 16:47, David Hildenbrand (Arm) wrote:
>> On 8/6/26 16:42, Cédric Le Goater wrote:
>>>
>>> There are quite a few of these in the code in fact.
>>>
>>>
>>> It's a one liner. Good enough to raise the discussion no ?
>>
>> Just to be clear: Unchecked AI slop in any form is making my life worse every
>> day.
>>
> 
> Point taken. This is not the case here. There is quite a lot of work
> behind this from several people on the analysis.
The problem is that any sign of slop makes one assume that possibly everything
is slop and you don't know what to even believe anymore. :)

-- 
Cheers,

David

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[Jason Gunthorpe]

On Thu, Aug 06, 2026 at 04:47:07PM +0200, David Hildenbrand (Arm) wrote:
> On 8/6/26 16:42, Cédric Le Goater wrote:
> > On 8/6/26 16:28, Lorenzo Stoakes (ARM) wrote:
> >> On Thu, Aug 06, 2026 at 04:26:20PM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>> emdash in a code comment?
> > 
> > There are quite a few of these in the code in fact.
> > 
> >>> Then I spot
> >>>
> >>>     Assisted-by: Claude:claude-opus-4
> >>>
> >>> and really have to shake my head.
> > 
> > It's a one liner. Good enough to raise the discussion no ?
> 
> Just to be clear: Unchecked AI slop in any form is making my life
> worse every day.

I think eveyone's life who contributes reguarly to the kernel.. The
only ones who seem to benifit are people doing drive by patches!

There is so much more harder work on the maintainer side, and it is
now even harder to get patches picked up on the submitter side.

Yet responsible use of AI seems genuinely helpful and quality improving :\

Jason

Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

[David Hildenbrand (Arm)]

On 8/6/26 18:45, Jason Gunthorpe wrote:
> On Thu, Aug 06, 2026 at 04:47:07PM +0200, David Hildenbrand (Arm) wrote:
>> On 8/6/26 16:42, Cédric Le Goater wrote:
>>>
>>> There are quite a few of these in the code in fact.
>>>
>>>
>>> It's a one liner. Good enough to raise the discussion no ?
>>
>> Just to be clear: Unchecked AI slop in any form is making my life
>> worse every day.
> 
> I think eveyone's life who contributes reguarly to the kernel.. The
> only ones who seem to benifit are people doing drive by patches!
> 
> There is so much more harder work on the maintainer side, and it is
> now even harder to get patches picked up on the submitter side.
> 
> Yet responsible use of AI seems genuinely helpful and quality improving :\

yeah, I run all my stuff through at least some basic AI review to give me more
confident that I am not missing extremely obvious things.

-- 
Cheers,

David

AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Lorenzo Stoakes (ARM)]

-cc some people to make it clear this is a general point not aimed at
anybody in particular.

On Thu, Aug 06, 2026 at 01:45:17PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 06, 2026 at 04:47:07PM +0200, David Hildenbrand (Arm) wrote:
> > Just to be clear: Unchecked AI slop in any form is making my life
> > worse every day.
>
> I think eveyone's life who contributes reguarly to the kernel.. The
> only ones who seem to benifit are people doing drive by patches!

And they shouldn't - we should make sure that nobody doing this can
benefit.

This is why I've revised my 'I will never take somebody's patch from them
and do it myself' policy.

If you do AI slop I will ALWAYS do this (if your AI has found a real issue
and if I am able to without burning out) or just say no and push it to a
TODO.

>
> There is so much more harder work on the maintainer side, and it is
> now even harder to get patches picked up on the submitter side.

Yup it's all awful.

>
> Yet responsible use of AI seems genuinely helpful and quality improving :\

Yes and I use it daily. It's really helpful when kept on a short leash...

We're going to have to move to a trust model eventually IMO where random
new people just don't get to apply anything until they build trust with
smaller changes (and with measures for established people who start
sloppping).

It sucks but it's the only workable solution IMO.

>
> Jason

--
Cheers, Lorenzo

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[John Hubbard]

On 8/6/26 9:50 AM, Lorenzo Stoakes (ARM) wrote:
> On Thu, Aug 06, 2026 at 01:45:17PM -0300, Jason Gunthorpe wrote:
>> On Thu, Aug 06, 2026 at 04:47:07PM +0200, David Hildenbrand (Arm) wrote:
>>> Just to be clear: Unchecked AI slop in any form is making my life
>>> worse every day.
>>
>> I think eveyone's life who contributes reguarly to the kernel.. The
>> only ones who seem to benifit are people doing drive by patches!
> 
> And they shouldn't - we should make sure that nobody doing this can
> benefit.
...
>> Yet responsible use of AI seems genuinely helpful and quality improving :\
> 
> Yes and I use it daily. It's really helpful when kept on a short leash...

haha so true. A *very* short leash! :)

> 
> We're going to have to move to a trust model eventually IMO where random
> new people just don't get to apply anything until they build trust with
> smaller changes (and with measures for established people who start
> sloppping).

That sounds like a good move! It really is all about who sends these patches,
and what their stance is toward creating patches.

And furthermore, that's not even a change in policy! Because traditionally,
that's how people started anyway: with small patches and patience. It's
only with AI that they've been able to skip that step, to everyone's
detriment.

There are some patchsets in my inbox that I instinctively just skipped,
because they were huge new patchsets from new AIs (not people, really),
only to watch in dismay as they burned up other people's time in
review attempts.

thanks,
-- 
John Hubbard

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Zi Yan]

On 6 Aug 2026, at 13:05, John Hubbard wrote:

> On 8/6/26 9:50 AM, Lorenzo Stoakes (ARM) wrote:
>> On Thu, Aug 06, 2026 at 01:45:17PM -0300, Jason Gunthorpe wrote:
>>> On Thu, Aug 06, 2026 at 04:47:07PM +0200, David Hildenbrand (Arm) wrote:
>>>> Just to be clear: Unchecked AI slop in any form is making my life
>>>> worse every day.
>>>
>>> I think eveyone's life who contributes reguarly to the kernel.. The
>>> only ones who seem to benifit are people doing drive by patches!
>>
>> And they shouldn't - we should make sure that nobody doing this can
>> benefit.
> ...
>>> Yet responsible use of AI seems genuinely helpful and quality improving :\
>>
>> Yes and I use it daily. It's really helpful when kept on a short leash...
>
> haha so true. A *very* short leash! :)
>
>>
>> We're going to have to move to a trust model eventually IMO where random
>> new people just don't get to apply anything until they build trust with
>> smaller changes (and with measures for established people who start
>> sloppping).
>
> That sounds like a good move! It really is all about who sends these patches,
> and what their stance is toward creating patches.
>
> And furthermore, that's not even a change in policy! Because traditionally,
> that's how people started anyway: with small patches and patience. It's

Patience is the key. Seeing patches refreshed within a day is killing me.

> only with AI that they've been able to skip that step, to everyone's
> detriment.
>
> There are some patchsets in my inbox that I instinctively just skipped,
> because they were huge new patchsets from new AIs (not people, really),
> only to watch in dismay as they burned up other people's time in
> review attempts.
>
> thanks,
> -- 
> John Hubbard


Best Regards,
Yan, Zi

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Gregory Price]

On Thu, Aug 06, 2026 at 01:08:15PM -0400, Zi Yan wrote:
> On 6 Aug 2026, at 13:05, John Hubbard wrote:
> 
> > And furthermore, that's not even a change in policy! Because traditionally,
> > that's how people started anyway: with small patches and patience. It's
> 
> Patience is the key. Seeing patches refreshed within a day is killing me.
>

some kind of 2-stage filtering mechanism maybe?

mm gets everything
mm-review is curated from mm to reduce noise

Maybe would have to leverage a model though to surface critical things.

Just an idea.

~Gregory

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Zi Yan]

On 6 Aug 2026, at 13:40, Gregory Price wrote:

> On Thu, Aug 06, 2026 at 01:08:15PM -0400, Zi Yan wrote:
>> On 6 Aug 2026, at 13:05, John Hubbard wrote:
>>
>>> And furthermore, that's not even a change in policy! Because traditionally,
>>> that's how people started anyway: with small patches and patience. It's
>>
>> Patience is the key. Seeing patches refreshed within a day is killing me.
>>
>
> some kind of 2-stage filtering mechanism maybe?
>
> mm gets everything
> mm-review is curated from mm to reduce noise
>
> Maybe would have to leverage a model though to surface critical things.
>
> Just an idea.

netdev has their patch review queue: https://netdev.bots.linux.dev/suie.html

source: https://github.com/kuba-moo/suie

Hope we can get something similar. :)


Best Regards,
Yan, Zi

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Lorenzo Stoakes (ARM)]

On Thu, Aug 06, 2026 at 12:40:16PM -0500, Gregory Price wrote:
> On Thu, Aug 06, 2026 at 01:08:15PM -0400, Zi Yan wrote:
> > On 6 Aug 2026, at 13:05, John Hubbard wrote:
> >
> > > And furthermore, that's not even a change in policy! Because traditionally,
> > > that's how people started anyway: with small patches and patience. It's
> >
> > Patience is the key. Seeing patches refreshed within a day is killing me.
> >
>
> some kind of 2-stage filtering mechanism maybe?
>
> mm gets everything
> mm-review is curated from mm to reduce noise
>
> Maybe would have to leverage a model though to surface critical things.
>
> Just an idea.

No I don't want slop going anywhere, at all. Nothing.

If you slop the reward should be silence ideally. And certainly not anything you
slopped going to any kind of branch... :)

The slopularity is upon is Gregory. Behold the desert of the real etc.

>
> ~Gregory

--
Cheers, Lorenzo

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Gregory Price]

On Thu, Aug 06, 2026 at 06:42:49PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Thu, Aug 06, 2026 at 12:40:16PM -0500, Gregory Price wrote:
> >
> > mm gets everything
> > mm-review is curated from mm to reduce noise
> >
> > Maybe would have to leverage a model though to surface critical things.
> >
> > Just an idea.
> 
> No I don't want slop going anywhere, at all. Nothing.
> 
> If you slop the reward should be silence ideally. And certainly not anything you
> slopped going to any kind of branch... :)
> 
> The slopularity is upon is Gregory. Behold the desert of the real etc.
>

I understand the sentiment, but then we have to reduce this to practice.

And unfortunately, I'm about 99% sure that identifying slop is rapidly
going to approach undecidability.  We're lucky it still emits em-dashes.

Unless we plan on converting the list to semi-public (which feels the
anti-thesis of Linux), i'm not sure how you get there from here.

So the risk is - do you over-bury and make it invisible, knowing we'll
miss legitimate bugs and fixes - or do you do something (anything) that
helps you ignore it while still being inspectable and curated.

And burning tokens to fight tokens is just blatantly a losing battle.

~Gregory

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Lorenzo Stoakes (ARM)]

On Thu, Aug 06, 2026 at 02:28:30PM -0500, Gregory Price wrote:
> On Thu, Aug 06, 2026 at 06:42:49PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Thu, Aug 06, 2026 at 12:40:16PM -0500, Gregory Price wrote:
> > >
> > > mm gets everything
> > > mm-review is curated from mm to reduce noise
> > >
> > > Maybe would have to leverage a model though to surface critical things.
> > >
> > > Just an idea.
> >
> > No I don't want slop going anywhere, at all. Nothing.
> >
> > If you slop the reward should be silence ideally. And certainly not anything you
> > slopped going to any kind of branch... :)
> >
> > The slopularity is upon is Gregory. Behold the desert of the real etc.
> >
>
> I understand the sentiment, but then we have to reduce this to practice.
>
> And unfortunately, I'm about 99% sure that identifying slop is rapidly
> going to approach undecidability.  We're lucky it still emits em-dashes.

Well this is exactly why I think the trust model is literally the only
feasible one.

If you're unknown/known but -> slop then >/dev/null.

It's the only thing that's going to work.

And you build trust by doing small patches and review. Yes that can be
slopped but until AI becomes indistinguishable from a human (which would
eliminate the problem anyway) there's a human and there's a not-human way
of doing that.

Important that the trust can go the other way if bad behaviour is observed.

>
> Unless we plan on converting the list to semi-public (which feels the
> anti-thesis of Linux), i'm not sure how you get there from here.
>
> So the risk is - do you over-bury and make it invisible, knowing we'll
> miss legitimate bugs and fixes - or do you do something (anything) that
> helps you ignore it while still being inspectable and curated.

Trust model should solve that too. If a good faith established individual
or company submits valid bug reports then fine.

And hopefully we'll have some sensible means of handling passive bug
reporting (which emphatically is NOT the hateful sashiko 'this isn't
related to the patch but' stuff) and motivated parties to make the AI stuff
work but under maintainer control.

Because burnout was a thing and now it's what's going to happen to EVERY
kernel maintainer unless pretty drastic steps are taken IMO.

>
> And burning tokens to fight tokens is just blatantly a losing battle.

Yep, not going to work long-term.

>
> ~Gregory

--
Cheers, Lorenzo

Re: AI slop (was Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP) policy check

[Lorenzo Stoakes (ARM)]

On Thu, Aug 06, 2026 at 01:08:15PM -0400, Zi Yan wrote:
> On 6 Aug 2026, at 13:05, John Hubbard wrote:
>
> > On 8/6/26 9:50 AM, Lorenzo Stoakes (ARM) wrote:
> >> On Thu, Aug 06, 2026 at 01:45:17PM -0300, Jason Gunthorpe wrote:
> >>> On Thu, Aug 06, 2026 at 04:47:07PM +0200, David Hildenbrand (Arm) wrote:
> >>>> Just to be clear: Unchecked AI slop in any form is making my life
> >>>> worse every day.
> >>>
> >>> I think eveyone's life who contributes reguarly to the kernel.. The
> >>> only ones who seem to benifit are people doing drive by patches!
> >>
> >> And they shouldn't - we should make sure that nobody doing this can
> >> benefit.
> > ...
> >>> Yet responsible use of AI seems genuinely helpful and quality improving :\
> >>
> >> Yes and I use it daily. It's really helpful when kept on a short leash...
> >
> > haha so true. A *very* short leash! :)

Very very :)

> >
> >>
> >> We're going to have to move to a trust model eventually IMO where random
> >> new people just don't get to apply anything until they build trust with
> >> smaller changes (and with measures for established people who start
> >> sloppping).
> >
> > That sounds like a good move! It really is all about who sends these patches,
> > and what their stance is toward creating patches.
> >
> > And furthermore, that's not even a change in policy! Because traditionally,
> > that's how people started anyway: with small patches and patience. It's

I should know, I did the Eudyptula challenge then stuff in the staging drivers
then I wrote a book etc. you know the usual stuff :P

It took years because it's you know a lot. And I still don't really understand
anything (therein lies the zen state of knowing enough to know ones own
incredible ignorance... :)

>
> Patience is the key. Seeing patches refreshed within a day is killing me.

Tell me about it :) the workslopload since the slopularity (circa
late 2025) is slopcrazy.

We so need some kind of a support group... maybe at LPC? :) I nominate the
pub as the venue for this...

>
> > only with AI that they've been able to skip that step, to everyone's
> > detriment.

Yeah. And also there are a number of people who, bless them, simply could
never get to the point of being able to contribute.

I really do think talent is a factor (I know for some this is a
controversial position) as well as bloody-mindedness, a certain way of
thinking about perhaps some masochism thrown in there somewhere ;)

I think only a small % of a small % have what it takes.

In the past those who could not, would not, even if they tried a little
first.

Now those who can not, do, but do so with absolutely no understanding or
sane guardrails (Dunning Kruger comes into play here also).

> >
> > There are some patchsets in my inbox that I instinctively just skipped,
> > because they were huge new patchsets from new AIs (not people, really),
> > only to watch in dismay as they burned up other people's time in
> > review attempts.

I fear doing so in case things end up getting merged mistakenly.

But I am certainly a lot more quickly dismissive of this crap than I used
to be, simply because I only have finite time and an infinite amount of
work to do :)

> >
> > thanks,
> > --
> > John Hubbard
>
>
> Best Regards,
> Yan, Zi

--
Cheers, Lorenzo