From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C5D9353EEB for ; Fri, 11 Sep 2026 05:15:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789103738; cv=none; b=Yw6P0lJiUPNjzmR7ejBcYH9bMWOLXK29WyuHkmS0HGMLOZzQ+sW7IQcej+KPWcWgmD4dbSBX9o1K99ILJsEmczW/3ZJWisXVpbgB4dd1oG61jXflJ/lrWB9J93umsLDKMVjgDC8oE3Fo63LLQakaLThhn1mBcZVgI/Ea7BCtVm8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789103738; c=relaxed/simple; bh=EB101r6YBNXyaonISD6MjCBEYQKArTbpVxUGBG6d10k=; h=Date:To:From:Subject:Message-Id; b=eZZUwO//wwIPWVXD/OG0wHpSzpITP5jSunhVjiUzhFlSXFobPBTHsIhTMVt7G/AvOVXTE93DAlmeuQhgRCkWaws0qvL4Jv5VAXShvCHS1UaCV5etpy9qtirLWCUbbOGlJWY5sgH/W9td+DwtET3BFMqQ8Sp67f8g+3KjRbMQCiM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=MuAioUl6; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="MuAioUl6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19B131F00893; Fri, 11 Sep 2026 05:15:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1789103736; bh=aDX8rmRwUj6sBpKptveDtUrpfc1iwT6gmUii5+bl0M0=; h=Date:To:From:Subject; b=MuAioUl6lVnd4r4R71N1bQNaQ9Rn7CyD7uxIPxmixGK97/PmssL8rYP12NqYyUwLr F/CaeZYwxAW/9I8lvKOfuJI19iUQuTcXNlS8kRkOJvv23nB/Of4e1ixQ5PTxHYYvE+ sKOS4Y4ze+gVqmrp/m06308+kuogGGddp1xx4fvk= Date: Thu, 10 Sep 2026 22:15:35 -0700 To: mm-commits@vger.kernel.org,songmuchun@bytedance.com,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization.patch added to mm-new branch Message-Id: <20260911051536.19B131F00893@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm/sparse-vmemmap: introduce CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION has been added to the -mm mm-new branch. Its filename is mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization.patch This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. The mm-new branch of mm.git is not included in linux-next If a few days of testing in mm-new is successful, the patch will me moved into mm.git's mm-unstable branch, which is included in linux-next Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Muchun Song Subject: mm/sparse-vmemmap: introduce CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION Date: Fri, 11 Sep 2026 13:02:18 +0800 Patch series "mm: Switch device DAX to section-based vmemmap optimization", v3. This series is split out from the earlier, larger series "mm: Generalize HVO for HugeTLB and device DAX" [1]. While the parent series generalizes vmemmap optimization across HugeTLB and device DAX, this subset addresses a single, self-contained step: switching device DAX to the section-based sparse-vmemmap optimization infrastructure introduced for HugeTLB. After the HugeTLB conversion, optimized vmemmap state is described by the memory section and the sparse-vmemmap population path can allocate or reuse shared tail vmemmap pages based on that metadata. Device DAX still uses the older DAX-specific population model, including a separate tail vmemmap page reservation and architecture-specific logic to locate or populate reusable tail pages. This series makes device DAX use the same section-based model. Device DAX records the compound page order from pgmap->vmemmap_shift in section metadata before vmemmap population, uses the common per-zone shared tail vmemmap page, and drops the extra reserved tail page. The powerpc radix path is updated to use the same shared tail-page helper, so the generic and powerpc DAX paths follow the same reservation model. The first patches prepare the shared infrastructure by introducing a generic CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION symbol, factoring out shared tail-page allocation, and keeping the special shared-tail struct page initialization local to sparse-vmemmap. The middle patches move device DAX onto that infrastructure by recording the device DAX compound page order in memory-section metadata, using that metadata to back generic device DAX mappings with the common per-zone shared tail page, exposing the shared helpers so the powerpc radix path can use the same model, and dropping the extra DAX-only tail page reservation and the now-unused section accounting arguments. The final patch updates the documentation for the new DAX layout. This is intended to be the third smaller step toward the broader HVO generalization. The wider HVO consolidation between HugeTLB and device DAX is left for follow-up series. This patch (of 11): The section-based vmemmap optimization infrastructure is still guarded by CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP, but it also can be used by device DAX. Introduce CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION as a common config for the shared infrastructure. Select the new option from HUGETLB_PAGE_OPTIMIZE_VMEMMAP and from DEV_DAX when the architecture opts in to DAX vmemmap optimization, and use it to guard the generic sparse-vmemmap state and helpers. Link: https://lore.kernel.org/20260911050228.58884-1-songmuchun@bytedance.com Link: https://lore.kernel.org/20260911050228.58884-2-songmuchun@bytedance.com Link: https://lore.kernel.org/all/20260513130542.35604-1-songmuchun@bytedance.com/ [1] Signed-off-by: Muchun Song Acked-by: Qi Zheng Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Mike Rapoport Cc: Nicholas Piggin Cc: Oscar Salvador Cc: Randy Dunlap Signed-off-by: Andrew Morton --- arch/x86/entry/vdso/vdso32/fake_32bit_build.h | 2 +- drivers/dax/Kconfig | 2 ++ fs/Kconfig | 1 + include/linux/mm.h | 3 +++ include/linux/mmzone.h | 13 +++++++------ include/linux/page-flags.h | 5 ++--- mm/Kconfig | 4 ++++ mm/sparse.h | 4 ++-- 8 files changed, 22 insertions(+), 12 deletions(-) --- a/arch/x86/entry/vdso/vdso32/fake_32bit_build.h~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/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_SPARSEMEM_VMEMMAP_OPTIMIZATION #undef CONFIG_NR_CPUS #undef CONFIG_PARAVIRT_XXL --- a/drivers/dax/Kconfig~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/drivers/dax/Kconfig @@ -8,6 +8,8 @@ if DAX config DEV_DAX tristate "Device DAX: direct access mapping device" depends on TRANSPARENT_HUGEPAGE + depends on ZONE_DEVICE + select SPARSEMEM_VMEMMAP_OPTIMIZATION if ARCH_WANT_OPTIMIZE_DAX_VMEMMAP help Support raw access to differentiated (persistence, bandwidth, latency...) memory via an mmap(2) capable character --- a/fs/Kconfig~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/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 SPARSEMEM_VMEMMAP_OPTIMIZATION config HUGETLB_PMD_PAGE_TABLE_SHARING def_bool HUGETLB_PAGE --- a/include/linux/mm.h~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/include/linux/mm.h @@ -5175,6 +5175,9 @@ static inline bool __vmemmap_can_optimiz unsigned long nr_pages; unsigned long nr_vmemmap_pages; + if (!IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION)) + return false; + if (!pgmap || !is_power_of_2(sizeof(struct page))) return false; --- a/include/linux/mmzone.h~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/include/linux/mmzone.h @@ -102,9 +102,9 @@ * * HVO which is only active if the size of struct page is a power of 2. */ -#define MAX_FOLIO_VMEMMAP_ALIGN \ - (IS_ENABLED(CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP) && \ - is_power_of_2(sizeof(struct page)) ? \ +#define MAX_FOLIO_VMEMMAP_ALIGN \ + (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION) && \ + is_power_of_2(sizeof(struct page)) ? \ MAX_FOLIO_NR_PAGES * sizeof(struct page) : 0) /* The number of retained vmemmap pages with HVO enabled. */ @@ -116,7 +116,8 @@ #define __VMEMMAP_OPTIMIZATION_NR_ORDERS \ (MAX_FOLIO_ORDER - VMEMMAP_OPTIMIZATION_MIN_ORDER + 1) #define VMEMMAP_OPTIMIZATION_NR_ORDERS \ - (__VMEMMAP_OPTIMIZATION_NR_ORDERS > 0 ? __VMEMMAP_OPTIMIZATION_NR_ORDERS : 0) + ((__VMEMMAP_OPTIMIZATION_NR_ORDERS > 0 && \ + IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION)) ? __VMEMMAP_OPTIMIZATION_NR_ORDERS : 0) enum migratetype { MIGRATE_UNMOVABLE, @@ -1155,7 +1156,7 @@ struct zone { /* Zone statistics */ atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS]; atomic_long_t vm_numa_event[NR_VM_NUMA_EVENT_ITEMS]; -#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP +#ifdef CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION struct page *vmemmap_tails[VMEMMAP_OPTIMIZATION_NR_ORDERS]; #endif } ____cacheline_internodealigned_in_smp; @@ -2019,7 +2020,7 @@ struct mem_section { unsigned long section_mem_map; struct mem_section_usage *usage; -#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP +#ifdef CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION /* * Normally, sections hold regular (order-0) pages. However, for * sections with HVO enabled, this tracks the compound page order --- a/include/linux/page-flags.h~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/include/linux/page-flags.h @@ -208,14 +208,13 @@ enum pageflags { static __always_inline bool compound_info_has_mask(void) { /* - * Limit mask usage to HugeTLB vmemmap optimization (HVO) where it - * makes a difference. + * Limit mask usage to HVO where it makes a difference. * * The approach with mask would work in the wider set of conditions, * but it requires validating that struct pages are naturally aligned * for all orders up to the MAX_FOLIO_ORDER, which can be tricky. */ - if (!IS_ENABLED(CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP)) + if (!IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION)) return false; return is_power_of_2(sizeof(struct page)); --- a/mm/Kconfig~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/mm/Kconfig @@ -461,6 +461,10 @@ config SPARSEMEM_VMEMMAP pfn_to_page and page_to_pfn operations. This is the most efficient option when sufficient kernel resources are available. +config SPARSEMEM_VMEMMAP_OPTIMIZATION + bool + depends on SPARSEMEM_VMEMMAP + # # Select this config option from the architecture Kconfig, if it is preferred # to enable the feature of HugeTLB/dev_dax vmemmap optimization. --- a/mm/sparse.h~mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization +++ a/mm/sparse.h @@ -10,7 +10,7 @@ #include -#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP +#ifdef CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION static inline unsigned int section_compound_order(const struct mem_section *section) { return section->compound_page_order; @@ -75,7 +75,7 @@ static inline bool vmemmap_optimizable_p static inline bool vmemmap_optimizable_order(unsigned int order) { - if (!IS_ENABLED(CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP)) + if (!IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP_OPTIMIZATION)) return false; if (!is_power_of_2(sizeof(struct page))) _ Patches currently in -mm which might be from songmuchun@bytedance.com are mm-sparse-relax-struct-mem_section-size-constraints.patch mm-sparse-vmemmap-rename-hvo-order-macros.patch mm-mm_init-skip-initializing-shared-vmemmap-tail-pages.patch mm-sparse-vmemmap-initialize-shared-tail-vmemmap-pages-on-allocation.patch mm-sparse-vmemmap-support-section-based-vmemmap-accounting.patch mm-mm_init-factor-out-pfn_to_zone.patch mm-sparse-vmemmap-move-helpers-ahead-of-future-callers.patch mm-sparse-vmemmap-support-section-based-vmemmap-optimization.patch mm-sparse-initialize-memory-sections-earlier.patch mm-hugetlb-switch-hugetlb-to-section-based-vmemmap-optimization.patch mm-sparse-vmemmap-remove-sparsemem_vmemmap_preinit-support.patch mm-sparse-inline-usemap-allocation-into-sparse_init_nid.patch mm-sparse-remove-section_map_size.patch mm-hugetlb-remove-huge_bootmem_hvo.patch mm-hugetlb-remove-huge_bootmem_cma.patch mm-hugetlb-localize-struct-huge_bootmem_page.patch mm-hugetlb-localize-huge_bootmem_zones_valid.patch mm-sparse-vmemmap-introduce-config_sparsemem_vmemmap_optimization.patch mm-sparse-vmemmap-factor-out-shared-vmemmap-tail-page-allocation.patch mm-sparse-vmemmap-open-code-init_compound_tail.patch mm-sparse-vmemmap-prepare-dax-vmemmap-population-for-compound-page-orders.patch mm-sparse-vmemmap-set-compound-page-order-for-device-dax.patch mm-sparse-vmemmap-switch-device-dax-to-shared-tail-vmemmap-pages.patch mm-sparse-vmemmap-move-vmemmap-optimization-helpers-to-a-public-header.patch powerpc-mm-switch-device-dax-to-shared-tail-vmemmap-pages.patch mm-sparse-vmemmap-drop-the-extra-tail-page-from-device-dax-reservation.patch mm-sparse-vmemmap-drop-unused-section_nr_vmemmap_pages-arguments.patch documentation-mm-update-dax-vmemmap-deduplication-docs.patch