Re: [PATCH v2 2/4] mm: Add file_operations.get_mapping_order()

[Jason Gunthorpe]

On Wed, Dec 10, 2025 at 03:23:02PM -0500, Peter Xu wrote:
> On Sun, Dec 07, 2025 at 12:21:32PM -0400, Jason Gunthorpe wrote:
> > On Thu, Dec 04, 2025 at 10:10:01AM -0500, Peter Xu wrote:
> > > Add one new file operation, get_mapping_order().  It can be used by file
> > > backends to report mapping order hints.
> > > 
> > > By default, Linux assumed we will map in PAGE_SIZE chunks.  With this hint,
> > > the driver can report the possibility of mapping chunks that are larger
> > > than PAGE_SIZE.  Then, the VA allocator will try to use that as alignment
> > > when allocating the VA ranges.
> > > 
> > > This is useful because when chunks to be mapped are larger than PAGE_SIZE,
> > > VA alignment matters and it needs to be aligned with the size of the chunk
> > > to be mapped.
> > > 
> > > Said that, no matter what is the alignment used for the VA allocation, the
> > > driver can still decide which size to map the chunks.  It is also not an
> > > issue if it keeps mapping in PAGE_SIZE.
> > > 
> > > get_mapping_order() is defined to take three parameters.  Besides the 1st
> > > parameter which will be the file object pointer, the 2nd + 3rd parameters
> > > being the pgoff + size of the mmap() request.  Its retval is defined as the
> > > order, which must be non-negative to enable the alignment.  When zero is
> > > returned, it should behave like when the hint is not provided, IOW,
> > > alignment will still be PAGE_SIZE.
> > 
> > This should explain how it works when the incoming pgoff is not
> > aligned..
> 
> Hmm, I thought the charm of this new proposal (based on suggestions of your
> v1 reviews) is to not need to worry on this..  Or maybe you meant I should
> add some doc comments in the commit message?

It can't be ignored, I don't think I ever said that. I said the driver
shouldn't have to worry about it, the core MM should deal with this.

> > I think for dpdk we want to support mapping around the MSI hole so
> > something like
> > 
> >  pgoff 0 -> 2M
> >  skip 4k
> >  2m + 4k -> 64M
> > 
> > Should setup the last VMA to align to 2M + 4k so the first PMD is
> > fragmented to 4k pages but the remaning part is 2M sized or better.
> > 
> > We just noticed a bug very similer to this in qemu around it's manual
> > alignment scheme where it would de-align things around the MSI window
> > and spoil the PMDs.
> 
> Right, IIUC this series should work all fine exactly as you said.

Are you sure? I did not see code doing this. The second mapping needs
to select a VA such that

  VA % 2M == 4k

And I don't see it doing that.

Jason