Re: [PATCH v7 1/7] arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE setup

[Will Deacon]

On Wed, Jul 15, 2026 at 08:08:07PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@xxxxxxxxxx>
> 
> For sizes aligned to CONT_PTE_SIZE and smaller than PMD_SIZE,
> we can handle CONT_PTE_SIZE groups together.
> 
> These additional sizes are mapping spans used by non-hugetlbfs(vmalloc)
> mm code, not new HugeTLB hstate sizes.
> 
> 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/mm/hugetlbpage.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index a42c05cf56408..7ce159483a354 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -94,6 +94,11 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
>  	return CONT_PTES;
>  }
> 
> +/*
> + * num_contig_ptes(), set_huge_pte_at() and arch_make_huge_pte() can be
> + * used by non-hugetlbfs(vmalloc) mm code to set multiple huge mappings
> + * at the PTE level.
> + */
>  static inline int num_contig_ptes(unsigned long size, size_t *pgsize)
>  {
>  	int contig_ptes = 1;
> @@ -110,6 +115,12 @@ static inline int num_contig_ptes(unsigned long size, size_t *pgsize)
>  		contig_ptes = CONT_PTES;
>  		break;
>  	default:
> +		if (size > 0 && size < PMD_SIZE &&
> +				IS_ALIGNED(size, CONT_PTE_SIZE)) {
> +			*pgsize = PAGE_SIZE;
> +			contig_ptes = size >> PAGE_SHIFT;
> +			break;
> +		}

Under which circumstances would you get a size of 0 here?

Given that you're relying on arch_vmap_pte_range_map_size() to give you
a well-formed size, why isn't if sufficient to check only the alignment?

>  		WARN_ON(!__hugetlb_valid_size(size));

I agree with David that it's messy having hugetlb tangled up in here.
It means this validity check is now going to miss some genuinely bogus
cases for the hugetlb path (as opposed to the vmalloc path).

Will