[PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode

[PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode

[Saravanan D]

The THP mode check in __thp_vma_allowable_orders() runs before the
clause that trusts huge_fault() handlers, so huge pfnmaps only
materialize when THP is set to "always". The THP modes exist to
limit the memory and khugepaged costs of transparent hugepages.
Special mappings are backed by pfns instead of THP folios and
khugepaged never scans them, so those costs do not apply and we
can exempt special mappings from the mode check. This also makes
THPeligible in smaps report 1 for such mappings.

This matters for VFIO device passthrough on distributions where
the default THP mode is "madvise". Mapping a 128 GiB GPU BAR
through VFIO_IOMMU_MAP_DMA costs 33.5 million order 0 faults and
20.7 seconds when the mode denies huge pfnmaps. With huge pfnmaps
allowed, the same mapping takes 128 PUD faults and 0.4 seconds.

Signed-off-by: Saravanan D <saravanand@crusoe.ai>
---
 mm/huge_memory.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index afbb5974bd22..bc61b8020af6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -193,9 +193,10 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
 	if (!vma_is_anonymous(vma)) {
 		/*
 		 * Enforce THP collapse requirements as necessary. Anonymous vmas
-		 * were already handled in thp_vma_allowable_orders().
+		 * were already handled in thp_vma_allowable_orders(). Special
+		 * mappings have no THP costs and are exempt.
 		 */
-		if (!forced_collapse &&
+		if (!forced_collapse && !vma_is_special_huge(vma) &&
 		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
 						    !hugepage_global_always())))
 			return 0;

base-commit: a032d41a86cb82a747bc14d9c82b3e153a9a9ab7
-- 
2.53.0

Re: [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode

[Lorenzo Stoakes (ARM)]

Nope.

On Fri, Aug 21, 2026 at 12:05:20AM -0700, Saravanan D wrote:
> The THP mode check in __thp_vma_allowable_orders() runs before the
> clause that trusts huge_fault() handlers, so huge pfnmaps only
> materialize when THP is set to "always". The THP modes exist to
> limit the memory and khugepaged costs of transparent hugepages.
> Special mappings are backed by pfns instead of THP folios and
> khugepaged never scans them, so those costs do not apply and we
> can exempt special mappings from the mode check. This also makes
> THPeligible in smaps report 1 for such mappings.
>
> This matters for VFIO device passthrough on distributions where
> the default THP mode is "madvise". Mapping a 128 GiB GPU BAR
> through VFIO_IOMMU_MAP_DMA costs 33.5 million order 0 faults and
> 20.7 seconds when the mode denies huge pfnmaps. With huge pfnmaps
> allowed, the same mapping takes 128 PUD faults and 0.4 seconds.
>
> Signed-off-by: Saravanan D <saravanand@crusoe.ai>

This seems like AI slop. We don't want it, thanks.

Read https://docs.kernel.org/process/coding-assistants.html and
https://docs.kernel.org/process/generated-content.html and follow kernel
guidelines please.

In any case if you'd taken 5 minutes to search the mailing list you'd see
this was:

a. Already submitted (so your patch reads like plagiarism).
b. Already rejected in favour of me doing an actually sensible solution.

https://lore.kernel.org/linux-mm/anL-NZkNMSSxN0YN@lucifer/

> ---
>  mm/huge_memory.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index afbb5974bd22..bc61b8020af6 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -193,9 +193,10 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>  	if (!vma_is_anonymous(vma)) {
>  		/*
>  		 * Enforce THP collapse requirements as necessary. Anonymous vmas
> -		 * were already handled in thp_vma_allowable_orders().
> +		 * were already handled in thp_vma_allowable_orders(). Special
> +		 * mappings have no THP costs and are exempt.
>  		 */
> -		if (!forced_collapse &&
> +		if (!forced_collapse && !vma_is_special_huge(vma) &&
>  		    (!hugepage_global_enabled() || (!(vm_flags & VM_HUGEPAGE) &&
>  						    !hugepage_global_always())))
>  			return 0;
>
> base-commit: a032d41a86cb82a747bc14d9c82b3e153a9a9ab7
> --
> 2.53.0
>

--
Cheers, Lorenzo

Re: [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode

[Saravanan D]

On Fri, Aug 21, 2026 at 09:03:15AM +0100, Lorenzo Stoakes (ARM) wrote:
> In any case if you'd taken 5 minutes to search the mailing list you'd see
> this was:
>
> a. Already submitted (so your patch reads like plagiarism).
> b. Already rejected in favour of me doing an actually sensible solution.
>
> https://lore.kernel.org/linux-mm/anL-NZkNMSSxN0YN@lucifer/

Apologies and please disregard my patch. I had not
searched the list before sending and was unaware of Cédric's patch
and your rework. Mine came from an independent observation of slow
VM boot times on Ubuntu based hosts running cloud-hypervisor with H100
GPUs. The patch was prepared with AI assistance and should have
carried an Assisted-by tag. All of my future submissions will.

I backported the diff you attached in your earlier response to
a 6.17 based kernel and ran it on a HGX host with four H100 GPUs,
each exposing a 128 GiB BAR1, with cloud-hypervisor. THP
mode was the Ubuntu default - madvise in all runs.

                       VFIO_IOMMU_MAP_DMA       4 GPU VM boot
                       per 128 GiB BAR
  6.17 unpatched             20.7s                   97s
  6.17 + your diff            0.4s                   17s

Each BAR mapped with 128 PUD faults. Your approach will definitely
improve VM boot times in our production. Very grateful for your
contribution.

Thanks,
Saravanan D.

Re: [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode

[Lorenzo Stoakes (ARM)]

On Fri, Aug 21, 2026 at 12:32:20PM -0700, Saravanan D wrote:
> On Fri, Aug 21, 2026 at 09:03:15AM +0100, Lorenzo Stoakes (ARM) wrote:
> > In any case if you'd taken 5 minutes to search the mailing list you'd see
> > this was:
> >
> > a. Already submitted (so your patch reads like plagiarism).
> > b. Already rejected in favour of me doing an actually sensible solution.
> >
> > https://lore.kernel.org/linux-mm/anL-NZkNMSSxN0YN@lucifer/
>
> Apologies and please disregard my patch. I had not
> searched the list before sending and was unaware of Cédric's patch
> and your rework. Mine came from an independent observation of slow
> VM boot times on Ubuntu based hosts running cloud-hypervisor with H100
> GPUs. The patch was prepared with AI assistance and should have
> carried an Assisted-by tag. All of my future submissions will.
>
> I backported the diff you attached in your earlier response to
> a 6.17 based kernel and ran it on a HGX host with four H100 GPUs,
> each exposing a 128 GiB BAR1, with cloud-hypervisor. THP
> mode was the Ubuntu default - madvise in all runs.
>
>                        VFIO_IOMMU_MAP_DMA       4 GPU VM boot
>                        per 128 GiB BAR
>   6.17 unpatched             20.7s                   97s
>   6.17 + your diff            0.4s                   17s
>
> Each BAR mapped with 128 PUD faults. Your approach will definitely
> improve VM boot times in our production. Very grateful for your
> contribution.

Thanks, always appreciate real world data :)

I will send the actual patch at some point it's on my never ending TODO
list... :)

>
> Thanks,
> Saravanan D.

--
Cheers, Lorenzo