On Mon, Dec 1, 2025 at 6:36 PM David Hildenbrand (Red Hat)
<[email protected]> 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
