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

[Dev Jain <dev.jain@arm.com>]

On 09/04/26 3:24 am, 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?

Yeah it will perhaps be better to have a fast-path detecting compound
pages, and if not then checking contiguity. So sure please go ahead
sharing some of my code and you can co-credit me.


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

Okay so I was under the impression that *not* splitting the page
will be problematic.

But, vmalloc splits pages because the caller can operate on
individual struct pages by vmalloc_to_page(). To the contrary,
since the caller of vmap() decides what kind of pages to
virtually-map, we don't have the problem I was raising. So
I guess we are fine by making vmap do huge-mappings by default.

> 
> Thanks
> Barry