From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5688396D0D for ; Fri, 21 Aug 2026 08:03:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787299404; cv=none; b=i2NFDNqZKqqMEOG4SgJ/KxL32CoU1nWdm248JhU0Pv/MmGgh6VaRUbr+nrmhE7N/e40mAyELGIBmxWAwW/ZuYx/LHJNJANnTW9AThQr8hEw/HxpANBvewysjub/i5DvcdDBFhg/z8AwKWkqULzi5tXSkchmfJlt80jnU8gOp2/M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787299404; c=relaxed/simple; bh=hcZFaTDi6CWCe+Rcg4qtmyDmNjiz+aqpqprDOpCMEa8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KDdO38vzlqpB06JpYfdy9lMCTL6Su7A1HzNUoVUaR1Xk0U/BN80g1oQCs+2Ezf7UW5nkhXDdRa5gnCsca1JUwZoYfzdTHeo0bl0oJ2+unLge8c1Paefgb+ZW4vQUmXpMsyFA8KJ+cgWe6G7/MUrVr7Oi9yZdLfprLLGZQRCQh54= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aYXyUBvH; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aYXyUBvH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73DAC1F000E9; Fri, 21 Aug 2026 08:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787299402; bh=Xl/eqcse8q01TGfMWGAYjBFpqsEhjPokKNvvi+tLs1Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aYXyUBvHuWjxr5r5eke88584RfNeQiUv+Z11RSeOyKCJggIp2nOOOkrdSWdQub4Oo FEmsOg1wM0tLHoJClvfXiLGGTuPCPmlyT0ak6hbN/HUGcC409TYNT1hUMrU7+3CkbK oEV7YcB8aSyGuYu9ujOHDN/hxTNq20RrzZ+2vDp1M62m5veKaUf9wVdMhzcm9D/fHt IipPH+TMQDy/DeS/BGCKZ9euJ3ugymN70cPWTNl8Y3qBGrrhRBGgt7ltQqma7NKJGx BzbrDqjhhZyfMSZVPoqVEKP1dZdaVhqgwdNlgait2VYyzRfa34YE7PS0dhPzQDrcKf lG8NCr2eeNcIQ== Date: Fri, 21 Aug 2026 09:03:15 +0100 From: "Lorenzo Stoakes (ARM)" To: Saravanan D Cc: Andrew Morton , linux-mm@kvack.org, 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@vger.kernel.org Subject: Re: [PATCH] mm/huge_memory: allow huge pfnmaps regardless of THP mode Message-ID: References: <20260821070520.25759-1-saravanand@crusoe.ai> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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