Re: [PATCH v9 05/10] arm64/vmalloc: allow arch_vmap_pte_range_map_size() to batch multiple CONT_PTE

[Uladzislau Rezki <urezki@gmail.com>]

On Thu, Oct 01, 2026 at 03:55:44PM +0800, Wen Jiang wrote:
> On Wed, 30 Sept 2026 at 23:38, Uladzislau Rezki <urezki@gmail.com> wrote:
> >
> > On Wed, Sep 23, 2026 at 02:28:27PM +0800, Wen Jiang wrote:
> > > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> > >
> > > Allow arch_vmap_pte_range_map_size to batch across multiple CONT_PTE
> > > blocks, reducing both PTE setup and TLB flush iterations.
> > >
> > > For CONT_PTE_SIZE-aligned ranges, return a mapping size that may cover
> > > multiple CONT_PTE blocks, capped below PMD_SIZE. These sizes are vmalloc
> > > mapping spans, not HugeTLB hstate sizes.
> > >
> > > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > > Tested-by: Leo Yan <leo.yan@arm.com>
> > > ---
> > >  arch/arm64/include/asm/vmalloc.h | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
> > > index 4ec1acd3c1b34..4053b1ec1902e 100644
> > > --- a/arch/arm64/include/asm/vmalloc.h
> > > +++ b/arch/arm64/include/asm/vmalloc.h
> > > @@ -23,10 +23,14 @@ 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
> > >        * 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;
> > > @@ -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);
> > >
> > Capped below PMD_SIZE? It is half of PMD_SIZE. Where is that limitation
> > comes from? I think the commit message should be improved in that sense.
> >
> 
> Hi Uladzislau,
> 
> You're right, and the "half" is a leftover that can be dropped entirely.
> 
> Before this series decoupled vmalloc from the HugeTLB, the value
> returned here was fed into ilog2, which reconstructs pagesize as
> 1UL << shift. That forced the size to be a power of two, and PMD_SIZE >> 1
> was then the largest power of two strictly below PMD_SIZE,
> 
> How that pte_set_huge() takes the size directly, the size only needs
> CONT_PTE_SIZE alignment. And this function is only ever called for
> a range that the caller has already confined to a single PMD via
> pmd_addr_end(), so no explicit PMD cap is needed at all. I'll
> simplify it to:
> 
>         size = min2(end -addr, 1UL << max_page_shift);
> 
> and update the commit message accordingly.
> 
Thank you!

--
Uladzislau Rezki