On Mon, Dec 1, 2025 at 6:36 PM David Hildenbrand (Red Hat) david@kernel.org wrote: [...]
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 0832f944544c..af2e3e8c052a 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -642,6 +642,34 @@ static int vmap_small_pages_range_noflush(unsigned long addr, unsigned long end, return err; }
+static inline int get_vmap_batch_order(struct page **pages,
unsigned int stride,int max_steps,unsigned int idx)These fit into less lines.
ideally
\t\tunsigned int stride, int max_steps, unsigned int idx)
Right, thanks!
+{
int order, nr_pages, i; struct page *base;
But I think you can just drop "base". And order.
Right, thanks!
/** Currently, batching is only supported in vmap_pages_range* when page_shift == PAGE_SHIFT.*/if (stride != 1)return 0;struct page *base = pages[idx];if (!PageHead(base))return 0;int order = compound_order(base);int nr_pages = 1 << order;You can drop the head check etc and simply do
nr_pages = compound_nr(pages[idx]); if (nr_pages == 1) return 0;
Nice. Since compound_nr() returns 1 for tail pages.
Which raises the question: are these things folios? I assume not.
In my case, it’s simply alloc_pages with GFP_COMP. I assume that folios allocated via folio_alloc() would also automatically benefit from this patch?
Currently, vmap() takes a pages array as an argument. So even for a folio, we need to expand it into individual pages. Simply passing a folios array to vmalloc likely won’t work, since vmap() could start and end at subpages in the middle of a folio.
Thanks Barry