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

[Anshuman Khandual]

On 15/07/26 8:19 AM, Wen Jiang wrote:
> 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.

Yes sounds good.
>   */
>   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
>>>