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.