Re: [PATCH v6 2/6] arm64/vmalloc: Allow arch_vmap_pte_range_map_size to batch multiple CONT_PTE

From: Wen Jiang

Date: Tue Jul 14 2026 - 05:25:02 EST


On Tue, 14 Jul 2026 at 15:13, Anshuman Khandual
<anshuman.khandual@xxxxxxx> wrote:
>
>
>
> On 09/07/26 1:08 PM, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@xxxxxxxxxx>
> >
> > Allow arch_vmap_pte_range_map_size to batch across multiple CONT_PTE
> > blocks, reducing both PTE setup and TLB flush iterations.
>
> Too little commit description for the proposed change here.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@xxxxxxxxxx>
> > Signed-off-by: Wen Jiang <jiangwen6@xxxxxxxxxx>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@xxxxxxxxx>
> > Tested-by: Leo Yan <leo.yan@xxxxxxx>
> > Reviewed-by: Dev Jain <dev.jain@xxxxxxx>
> > ---
> > arch/arm64/include/asm/vmalloc.h | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
> > index 4ec1acd3c1b34..7d9c7dc795c42 100644
> > --- a/arch/arm64/include/asm/vmalloc.h
> > +++ b/arch/arm64/include/asm/vmalloc.h
> > @@ -23,6 +23,8 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr,
> > unsigned long end, u64 pfn,
> > unsigned int max_page_shift)
> > {
> > + unsigned long size;
> > +
> > /*
> > * If the block is at least CONT_PTE_SIZE in size, and is naturally
> > * aligned in both virtual and physical space, then we can pte-map the
> > @@ -40,7 +42,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;
>
> Please do explain the fact in a comment that huge pte mappings
> upto PMD_SIZE are being allowed here, if the given block is
> CONT_PTE_SIZE aligned.
>
> IIUC arch_vmap_pte_range_map_size() gets used only when config
> CONFIG_HUGETLB_PAGE is enabled. Hence should not these new huge
> sizes being supported here also be added as valid HugeTLB sizes
> thus updating __hugetlb_valid_size() and adding corresponding
> new HugeTLB page sizes with hugetlb_add_hstate() ?
>
> OR could arch_vmap_pte_range_map_size() and set_huge_pte_at()
> can be updated for vmalloc without doing corresponding changes
> into HugeTLB itself ?

These sizes are not new HugeTLB page sizes. They are only vmalloc mapping
spans selected for a particular virtually and physically aligned range, so that
the PTEs can be installed with the contiguous bit in larger batches.

Therefore I do not think they should be added to __hugetlb_valid_size() or
registered with hugetlb_add_hstate(). Those describe the HugeTLB hstate sizes,
while this change only affects how vmalloc chooses the PTE-level mapping span.

Thanks,
Wen
> > }
> >
> > #define arch_vmap_pte_range_unmap_size arch_vmap_pte_range_unmap_size
>