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

[Wen Jiang]

On Tue, 14 Jul 2026 at 17:24, Wen Jiang <jiangwenxiaomi@xxxxxxxxx> wrote:
>
> 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.
> >

Hi Anshuman,

Would the following comment address your concern?

diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
--- a/arch/arm64/include/asm/vmalloc.h
+++ b/arch/arm64/include/asm/vmalloc.h
@@ -29,6 +29,8 @@ static inline unsigned long
arch_vmap_pte_range_map_size(unsigned long addr,
  * 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
  * block using the PTE_CONT bit for more efficient use of the TLB.
+ * The returned mapping size may cover multiple CONT_PTE_SIZE blocks,
+ * capped below PMD_SIZE.
  */
  if (max_page_shift < CONT_PTE_SHIFT)
  return PAGE_SIZE;

> > 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
> >