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

[Barry Song <baohua@kernel.org>]

On Wed, Apr 8, 2026 at 10:03 PM Dev Jain <dev.jain@arm.com> wrote:
>
>
>
> On 08/04/26 8:21 am, Barry Song (Xiaomi) wrote:
> > In many cases, the pages passed to vmap() may include high-order
> > pages allocated with __GFP_COMP flags. 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 high-order pages and maps them as a single
> > contiguous block whenever possible.
> >
> > An alternative would be to implement a new API, vmap_sg(), but that
> > change seems to be large in scope.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > ---
> >  mm/vmalloc.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 49 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index eba436386929..e8dbfada42bc 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3529,6 +3529,53 @@ void vunmap(const void *addr)
> >  }
> >  EXPORT_SYMBOL(vunmap);
> >
> > +static inline int get_vmap_batch_order(struct page **pages,
> > +             unsigned int max_steps, unsigned int idx)
> > +{
> > +     unsigned int nr_pages;
> > +
> > +     if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP) ||
> > +                     ioremap_max_page_shift == PAGE_SHIFT)
> > +             return 0;
> > +
> > +     nr_pages = compound_nr(pages[idx]);
> > +     if (nr_pages == 1 || max_steps < nr_pages)
> > +             return 0;
>
> This assumes that the page array passed to vmap() will have compound pages
> if it is a higher order allocation.
>
> See rb_alloc_aux_page(). It gets higher-order allocations without passing
> GFP_COMP.
>
> That is why my implementation does not assume anything about the property
> of the pages.

If you’re asking about support for non-compound pages, I think
that’s fine. My current use case is dma-buf, where pages are
compound. I recall discussing this previously with David and
Uladzislau.

If you’re working with non-compound pages, I’m happy to add
support in the next version. I’m also happy to reuse some of your
code and credit you as Co-developed-by if you’re willing. I actually
prefer your __vmap_huge() name over my
vmap_contig_pages_range().

Does that make sense to you?

>
> Also it may be useful to do regression-testing for the common case of
> vmap() with a single page (assuming it is common, I don't know), in
> which case we may have to special case it.

I agree, so I had Xueyuan test single pages and highlighted this
in the cover letter. There is no regression: "vmap() is 5.6×
faster when memory includes some order-8 pages, with no
regression observed for order-0 pages."

>
> My implementation requires opting in with VM_ALLOW_HUGE_VMAP - I suspect
> you may run into problems if you make vmap() do huge-mappings as best-effort
> by default. I am guessing this because ...
>
> Drivers can operate on individual pages, so vmalloc() calls split_page()
> and then does the block/cont mappings. This same issue should be present
> with vmap() too? In which case if we are to do huge-mappings by default
> then we can do split_page() after detecting contiguous chunks.
>
> But ... that may create problems for the caller of vmap() - vmap now
> has the changed the properties of the pages.

I don’t see this as a problem at all. Splitting pages does not
affect physical or virtual contiguity; it only changes the
contents of struct page objects, not the PTE/PMD mappings.
For ioremap, there isn’t even a struct page, yet the mappings
can still be huge.

Thanks
Barry