* [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode
@ 2026-08-21 7:05 Saravanan D
2026-08-21 8:03 ` Lorenzo Stoakes (ARM)
0 siblings, 1 reply; 2+ messages in thread
From: Saravanan D @ 2026-08-21 7:05 UTC (permalink / raw)
To: Andrew Morton, linux-mm
Cc: David Hildenbrand, Lorenzo Stoakes, Zi Yan, Baolin Wang,
Liam R . Howlett, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Usama Arif, Peter Xu, Alex Williamson, linux-kernel,
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
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode
2026-08-21 7:05 [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode Saravanan D
@ 2026-08-21 8:03 ` Lorenzo Stoakes (ARM)
0 siblings, 0 replies; 2+ messages in thread
From: Lorenzo Stoakes (ARM) @ 2026-08-21 8:03 UTC (permalink / raw)
To: Saravanan D
Cc: Andrew Morton, linux-mm, David Hildenbrand, Zi Yan, Baolin Wang,
Liam R . Howlett, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Usama Arif, Peter Xu, Alex Williamson, linux-kernel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-21 8:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-21 7:05 [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode Saravanan D
2026-08-21 8:03 ` Lorenzo Stoakes (ARM)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.