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

[Muchun Song <muchun.song@linux.dev>]

> On Sep 29, 2026, at 15:11, David Hildenbrand (Arm) <david@kernel.org> 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@bytedance.com>
>> Acked-by: Qi Zheng <qi.zheng@linux.dev>
>> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>> ---
>> 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@kernel.org>

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.

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.

[1] https://lore.kernel.org/20260708031129.3503195-1-jthoughton@google.com/
[2] https://lore.kernel.org/20260903122128.12264-2-songmuchun@bytedance.com/
[3] https://lore.kernel.org/20260513132044.41690-6-songmuchun@bytedance.com/


Thanks,
Muchun

> 
> 
> -- 
> Cheers,
> 
> David