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

[Peter Xu <peterx@redhat.com>]

On Tue, Dec 16, 2025 at 10:44:27AM -0400, Jason Gunthorpe wrote:
> 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.

I have an old program tested this, I ran it but I didn't mention it in the
cover letter.  I'm 99% sure it works like it, unless I'm seriously wrong
somewhere.

See:

https://github.com/xzpeter/clibs/blob/master/misc/vfio-pci-nofix.c

mmap BAR with memory ENABLED and read (offset=0x0, size=0x8000000)
mmap()=0x7f4395a00000 - 0.000117s
read(32768) - 0.085376s
mmap BAR with memory ENABLED and read (offset=0x1000, size=0x7fff000)
mmap()=0x7f4395a01000 - 0.000012s
read(32767) - 0.088642s
mmap BAR with memory ENABLED and read (offset=0x0, size=0x7fff000)
mmap()=0x7f4395a00000 - 0.000015s
read(32767) - 0.093850s
mmap BAR with memory ENABLED and read (offset=0x1000, size=0x7ffe000)
mmap()=0x7f4395a01000 - 0.000011s
read(32766) - 0.093248s

Also see __thp_get_unmapped_area() processed such pgoff, it allocates VA
with len_pad (not len), and pad the retval at last.

Please let me know if it didn't work like it, then it might be a bug.

Thanks,

-- 
Peter Xu