Re: [PATCH v5 03/12] mm/sparse-vmemmap: introduce CONFIG_VMEMMAP_OPTIMIZATION

From: David Hildenbrand (Arm)

Date: Tue Sep 29 2026 - 04:49:04 EST


On 9/29/26 09:53, Muchun Song wrote:
>
>
>> On Sep 29, 2026, at 15:11, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
>>
>> On 9/27/26 04:54, Muchun Song wrote:
>>> The section-based vmemmap optimization infrastructure is guarded by
>>> CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP, but it can also be used by
>>> ZONE_DEVICE users that set dev_pagemap::vmemmap_shift. Introduce
>>> CONFIG_VMEMMAP_OPTIMIZATION as a common config for the shared
>>> infrastructure.
>>>
>>> Select the new option from HUGETLB_PAGE_OPTIMIZE_VMEMMAP and from
>>> ZONE_DEVICE when the architecture opts in to DAX vmemmap optimization,
>>> and use it to guard the generic sparse-vmemmap state and helpers.
>>>
>>> Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
>>> Acked-by: Qi Zheng <qi.zheng@xxxxxxxxx>
>>> Acked-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
>>> ---
>>> v5:
>>> - Move this patch after the shared tail-page factoring.
>>> - Select VMEMMAP_OPTIMIZATION from ZONE_DEVICE instead of DEV_DAX,
>>> covering all users of dev_pagemap::vmemmap_shift, reported by
>>> Sashiko.
>>>
>>> v4:
>>> - Rename SPARSEMEM_VMEMMAP_OPTIMIZATION to VMEMMAP_OPTIMIZATION
>>> (suggested by Mike Rapoport)
>>> - Collect Acked-by from Mike Rapoport
>>>
>>> v2:
>>> - Fix SPARSEMEM_VMEMMAP_OPTIMIZATION being selected without SPARSEMEM_VMEMMAP
>>> reported by Sashiko.
>>> - Add an explicit DEV_DAX dependency on ZONE_DEVICE
>>> - Collect Acked-by from Qi Zheng
>>> ---
>>> arch/x86/entry/vdso/vdso32/fake_32bit_build.h | 2 +-
>>> fs/Kconfig | 1 +
>>> include/linux/mm.h | 3 +++
>>> include/linux/mmzone.h | 10 +++++-----
>>> include/linux/page-flags.h | 5 ++---
>>> mm/Kconfig | 5 +++++
>>> mm/sparse-vmemmap.c | 2 +-
>>> mm/sparse.h | 6 +++---
>>> 8 files changed, 21 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/arch/x86/entry/vdso/vdso32/fake_32bit_build.h b/arch/x86/entry/vdso/vdso32/fake_32bit_build.h
>>> index bc3e549795c3..72a92cb9b53d 100644
>>> --- a/arch/x86/entry/vdso/vdso32/fake_32bit_build.h
>>> +++ b/arch/x86/entry/vdso/vdso32/fake_32bit_build.h
>>> @@ -11,7 +11,7 @@
>>> #undef CONFIG_PGTABLE_LEVELS
>>> #undef CONFIG_ILLEGAL_POINTER_VALUE
>>> #undef CONFIG_SPARSEMEM_VMEMMAP
>>> -#undef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
>>> +#undef CONFIG_VMEMMAP_OPTIMIZATION
>>> #undef CONFIG_NR_CPUS
>>> #undef CONFIG_PARAVIRT_XXL
>>>
>>> diff --git a/fs/Kconfig b/fs/Kconfig
>>> index d1c210c6508f..1454b7fe9641 100644
>>> --- a/fs/Kconfig
>>> +++ b/fs/Kconfig
>>> @@ -278,6 +278,7 @@ config HUGETLB_PAGE_OPTIMIZE_VMEMMAP
>>> def_bool HUGETLB_PAGE
>>> depends on ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
>>> depends on SPARSEMEM_VMEMMAP
>>> + select VMEMMAP_OPTIMIZATION
>>
>> Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>
> Thanks.
>
>>
>> Is there a path to remove HUGETLB_PAGE_OPTIMIZE_VMEMMAP, and to merge
>> ARCH_WANT_OPTIMIZE_DAX_VMEMMAP+ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP into a
>> ARCH_SUPPORTS_VMEMMAP_OPTIMIZATION?
>
> These are actually two completely different capabilities.
>
> ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP requires the architecture
> to support dynamic updates to vmemmap page tables, meaning a
> PTE entry can be changed from one valid entry to another
> valid entry. This does not meet the requirements on arm64,
> because arm64 requires page table operations to satisfy BBM
> (there is, of course, a series [1] attempting to do this).
>
> However, for ARCH_WANT_OPTIMIZE_DAX_VMEMMAP, the vmemmap page
> tables do not involve dynamic updates, so the BBM requirement
> can be satisfied. Therefore, arm64 can enable
> ARCH_WANT_OPTIMIZE_DAX_VMEMMAP, but cannot enable
> ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP. To make the naming clearer,
> I have another patch [2] that renames it for greater clarity.

Ah, perfect. Too many patches floating around :)

I thought there is a patch set to avoid the BBM requirement on arm64 from James,
though. So not sure if both things will always stay separate.

>
> As for ARCH_WANT_OPTIMIZE_DAX_VMEMMAP, I plan to remove it
> entirely in the future, because architectures that do not support
> it can simply choose to disable it, as can be seen in patch [3].
>
> So in my plan, ultimately only one config will remain:
> ARCH_SUPPORTS_VMEMMAP_REMAP.
>
> I hope this clarifies the plan. Let me know what you think.

Yes, thanks.

--
Cheers,

David