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

[Jason Gunthorpe]

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..

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.

I guess ideally the file could return the order assuming an aligned-to-start
pgoff and the core code could use that order to compute an adjustment
for
the actual pgoff so we maintain:
  va % order = pgoff % order

Jason