Re: [PATCH] mm/huge_memory: let special huge VMAs bypass the THP policy check

On Wed, Aug 05, 2026 at 05:29:34PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Wed, Aug 05, 2026 at 09:15:24AM -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 05, 2026 at 07:55:40AM +0200, Cédric Le Goater wrote:
> >
> > > The result: each 256 GB BAR is mapped at 4 KiB granularity -- 67 million
> > > page faults per GPU instead of a few thousand PMD/PUD faults. On hosts
> > > with 8 GPUs (2 TB of BAR space), this causes VM boot times to degrade
> > > severely, with 99.98% of CPU time spent in the VFIO BAR mapping path.
> >
> > Broadly upstream we expect people to use iommufd and dmabuf for these
> > configurations to avoid all this nonsense overhead. :\
> 
> Point taken on that :) but I think it's generally reasonable in line with the
> huge PFN map changes to do something like I suggested.

Yeah, for cases like this working with pure PFNs from some non-folio
source the size should be entirely delegated to the driver, and driver
should always have the opportunity to place a maximally sized PTE.

It is definately wrong to intermix it with any THP logic. DAX isn't a
special case, it was just the first place to partially implement
something that looks like this.

Jason