Re: [PATCH] mm/vmalloc: map contiguous pages in batches for vmap() whenever possible

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 12/18/25 21:05, Barry Song wrote:
> [...]
>>>
>>> +static inline int get_vmap_batch_order(struct page **pages,
>>> +             unsigned int stride, unsigned int max_steps, unsigned int idx)
>>> +{
>>> +     int nr_pages = 1;
>>> +
>>> +     /*
>>> +      * Currently, batching is only supported in vmap_pages_range
>>> +      * when page_shift == PAGE_SHIFT.
>>> +      */
>>> +     if (stride != 1)
>>> +             return 0;
>>> +
>>> +     nr_pages = compound_nr(pages[idx]);
>>> +     if (nr_pages == 1)
>>> +             return 0;
>>> +     if (max_steps < nr_pages)
>>> +             return 0;
>>> +
>>> +     if (num_pages_contiguous(&pages[idx], nr_pages) == nr_pages)
>>> +             return compound_order(pages[idx]);
>>> +     return 0;
>>> +}
>>> +
>> Can we instead look at this as: it can be that we have continues
>> set of pages let's find out. I mean if we do not stick just to
>> compound pages.
> 
> We use PageCompound(pages[0]) and compound_nr() as quick
> filters to skip checking the contiguous count, and this is
> now the intended use case. Always checking contiguity might
> cause a slight regression, I guess.
> 
> BTW, do we have a strong use case where GFP_COMP or folio is
> not used, yet the pages are physically contiguous?

It usually happens by accident :)

E.g., allocate 2 pages and because we had to split an order-1 page into 
two order-0 pages, we get both of them.

Using num_pages_contiguous() only might indeed be nicer, but then we 
have to add some handling for getting aligned ranges (start and size 
aligned to order) ... so not sure if that is worth it.

-- 
Cheers

David