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

[Uladzislau Rezki <urezki@gmail.com>]

On Thu, Apr 09, 2026 at 05:54:55AM +0800, Barry Song wrote:
> 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.
>
It would be good if you could combine the work together with Jain.

--
Uladzislau Rezki