On 9/29/26 09:53, Muchun Song wrote: > > >> On Sep 29, 2026, at 15:11, David Hildenbrand (Arm) <[email protected]> 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 <[email protected]> >>> Acked-by: Qi Zheng <[email protected]> >>> Acked-by: Mike Rapoport (Microsoft) <[email protected]> >>> --- >>> 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) <[email protected]> > > 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
