All of lore.kernel.org
 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 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.