Re: [PATCH v7 2/7] arm64/vmalloc: Allow arch_vmap_pte_range_map_size to batch multiple CONT_PTE

[Barry Song]

On Tue, Jul 28, 2026 at 8:09 PM Will Deacon <will@xxxxxxxxxx> wrote:
>
[...]
> > @@ -40,7 +44,9 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr,
> >       if (!IS_ALIGNED(PFN_PHYS(pfn), CONT_PTE_SIZE))
> >               return PAGE_SIZE;
> >
> > -     return CONT_PTE_SIZE;
> > +     size = min3(end - addr, 1UL << max_page_shift, PMD_SIZE >> 1);
> > +     size = rounddown_pow_of_two(size);
> > +     return size;
>
> Why does this have to be a power of two? We should be able to work with
> regions where the start and end are suitably aligned. Is it because the
> hugetlb code works in terms of shifts?

Yep. For `vmap`, `vmalloc`, and `hugetlb`, this is all about
the page size shift, since their memory is typically backed by
the buddy allocator. However, after taking another look, I
think `ioremap()` could benefit. For example, if someone calls
`ioremap()` on a 576 KB region (64 KB * 9), we currently have
to map it as 512 KB + 64 KB. Without our patch, it would
require nine 64 KB mappings. If we allowed non-power-of-two
sizes, it could be mapped with single time.

So supporting non-power-of-two sizes might provide a small
performance benefit for `ioremap()`, although I suspect the
gain would be limited. I can investigate this as a follow-up
task, and if it turns out to provide a measurable improvement,
I can send an incremental patch.

Thanks
Barry