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

[Anshuman Khandual]

On 09/07/26 1:08 PM, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua at kernel.org>
> 
> 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 at kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6 at xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21 at gmail.com>
> Tested-by: Leo Yan <leo.yan at arm.com>
> Reviewed-by: Dev Jain <dev.jain at arm.com>
> ---
>  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 ?
>  }
>  
>  #define arch_vmap_pte_range_unmap_size arch_vmap_pte_range_unmap_size