[...]
+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?
Thanks Barry