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

[Lorenzo Stoakes (ARM)]

On Wed, Aug 05, 2026 at 01:52:40PM -0300, Jason Gunthorpe wrote:
> 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.

Might actually be worth getting rid of this dumb DAX special case and putting it
in the new thing too actually so it's actually normalised as 'statically mapped
stuff that doesn't allocate isn't gated on THP tunables' alongside huge PFN.

>
> Jason

--
Cheers, Lorenzo