The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Saravanan D <saravanand@crusoe.ai>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org,  David Hildenbrand <david@kernel.org>,
	Zi Yan <ziy@nvidia.com>,
	 Baolin Wang <baolin.wang@linux.alibaba.com>,
	"Liam R . Howlett" <liam@infradead.org>,
	 Nico Pache <nico.pache@linux.dev>,
	Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
	 Barry Song <baohua@kernel.org>,
	Lance Yang <lance.yang@linux.dev>,
	 Usama Arif <usama.arif@linux.dev>, Peter Xu <peterx@redhat.com>,
	 Alex Williamson <alex.williamson@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode
Date: Fri, 21 Aug 2026 09:03:15 +0100	[thread overview]
Message-ID: <aogCjEc9uyMjFP6S@gremlin> (raw)
In-Reply-To: <20260821070520.25759-1-saravanand@crusoe.ai>

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

  reply	other threads:[~2026-08-21  8:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]
2026-08-21 19:32   ` Saravanan D

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aogCjEc9uyMjFP6S@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nico.pache@linux.dev \
    --cc=peterx@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=saravanand@crusoe.ai \
    --cc=usama.arif@linux.dev \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox