Re: [PATCH v6 5/6] mm/vmalloc: map contiguous pages in batches for vmap() if possible

From: Wen Jiang

Date: Tue Jul 14 2026 - 01:20:15 EST


On Mon, 13 Jul 2026 at 23:19, Dev Jain <dev.jain@xxxxxxx> wrote:
>
>
>
> On 09/07/26 1:08 pm, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@xxxxxxxxxx>
> >
> > In many cases, the pages passed to vmap() may include high-order
> > pages. For example, the systemheap often allocates pages in descending
> > order: order 8, then 4, then 0. Currently, vmap() iterates over every
> > page individually—even pages inside a high-order block are handled
> > one by one.
> >
> > This patch detects physically contiguous pages (regardless of whether
> > they are compound or non-compound) by scanning with
> > num_pages_contiguous(), and maps them as a single contiguous block
> > whenever possible. The mapping order is determined by taking the
> > minimum of the contiguous page count and the pfn alignment, allowing
> > graceful degradation when pfn alignment is less than the contiguous
> > range.
> >
> > Pages with the same page_shift are coalesced and mapped via
> > vmap_pages_range_noflush_walk() to avoid page table rewalk.
> >
> > As users typically allocate memory in descending orders (e.g.
> > 8 → 4 → 0), once an order-0 page is encountered, we stop scanning
> > for contiguous pages since subsequent pages are likely order-0 as well.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@xxxxxxxxxx>
> > Co-developed-by: Dev Jain <dev.jain@xxxxxxx>
> > Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
> > Signed-off-by: Wen Jiang <jiangwen6@xxxxxxxxxx>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@xxxxxxxxx>
> > Tested-by: Leo Yan <leo.yan@xxxxxxx>
> > ---
> > mm/vmalloc.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 85 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index d2a4d649af549..db0492151ad08 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3543,6 +3543,89 @@ void vunmap(const void *addr)
> > }
> > EXPORT_SYMBOL(vunmap);
> >
> > +static inline unsigned int vm_shift(pgprot_t prot, unsigned long size)
> > +{
> > + if (arch_vmap_pmd_supported(prot) && size >= PMD_SIZE)
> > + return PMD_SHIFT;
> > +
> > + return arch_vmap_pte_supported_shift(size);
> > +}
>
> Need to throw in a preparatory patch for this, which will (in addition to
> introduction of the vm_shift() function) do:
>

Hi Dev,

Your suggestion is to extract "vm_shift" into a separate patch, say
Patch 5, to make it a common utility function just like Patch 3. And
move the existing code that can use vm_shift into this new patch as
well, correct?

Thanks,
Wen

> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index afaa14ebf17bb..dac87e1cd484b 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4175,10 +4175,7 @@ void *__vmalloc_node_range_noprof(unsigned long size, unsigned long align,
> * supporting them.
> */
>
> - if (arch_vmap_pmd_supported(prot) && size >= PMD_SIZE)
> - shift = PMD_SHIFT;
> - else
> - shift = arch_vmap_pte_supported_shift(size);
> + shift = vm_shift(prot, size);
>
> align = max(original_align, 1UL << shift);
> }
>
>
>
> > +
> > +static inline int get_vmap_batch_order(struct page **pages,
> > + pgprot_t prot, unsigned int max_steps, unsigned int idx)
> > +{
> > + unsigned int nr_contig;
> > + int order;
> > +
> > + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
> > + return 0;
> > +
> > + nr_contig = num_pages_contiguous(&pages[idx], max_steps);
> > + if (nr_contig < 2)
> > + return 0;
> > +
> > + order = ilog2(nr_contig);
> > +
> > + /* Limit order by pfn alignment */
> > + order = min_t(int, order, __ffs(page_to_pfn(pages[idx])));
>
> You missed Sashiko's point here :) the pfn may be zero and this
> will blow up. You can just first derive the pfn and do the clamping
> only when pfn > 0.
>
>

Will fix this.

Thanks,
Wen
>
> > +
> > + if (vm_shift(prot, PAGE_SIZE << order) == PAGE_SHIFT)
> > + return 0;
> > +
> > + return order;
> > +}
> > +