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

[Barry Song]

On Mon, Jul 20, 2026 at 4:16 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 7/15/26 13:08, 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 +++++++++++++++
>
> Huh, why are we touching hugetlbpage.c, which is HUGETLB-only material:
>
> $ cat arch/arm64/mm/Makefile  | grep hugetlbpage
> obj-$(CONFIG_HUGETLB_PAGE)      += hugetlbpage.o
>
> Something is off here, if vmalloc ends up reusing some of these helpers, they
> should probably get moved out here into common arm64 code.

This has been an issue since the original commit f7ee1f13d606c1
("mm/vmalloc: enable mapping of huge pages at pte level in vmap").

I agree that this likely needs some code reorganization. However, that would
probably be better handled as a separate follow-up series rather than as part
of this one, since it is not a small or trivial change.

The main problem is that the kernel lacks a set_ptes() helper for kernel
space. As a result, hugetlb has been repurposed for this across multiple
architectures since 2021 [1].

[1] https://lore.kernel.org/all/cover.1620795204.git.christophe.leroy@xxxxxxxxxx/

Best Regards
Barry