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 D5C7B364EA4 for ; Fri, 11 Sep 2026 05:15:47 +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=1789103750; cv=none; b=jT+lDGk0mD27NyNAI7XCKl7oyp7R2iYi9cuPkRXVprqSQhSWDiwZK3lFjo+2iBG3FltT7NCHZu0QVL4hxLTtpXua/mMA+HuHAwkfSXZlSsUJ8OWsTnzGRHrHrJ0mXWH0DpR1jj2AXwTLgwKg9tjHF2aFEv2H4/EQkilbSTg4moM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789103750; c=relaxed/simple; bh=IDwiaYXGJDtUkM0sDTWoZ91zhKgDSZbZ25dpaY/JUDE=; h=Date:To:From:Subject:Message-Id; b=lAL4Rde0VhE1JjXDYfWtQke7v+U7QIjw9pADO0s4NFXLC3hw5MXxw3ht9XN04/Yf5IBXzM+pmEv+ID4kUctHYGSAa4mQZ5aRz1oVKXY3KBx/DnWb91GDEFOv4uAVzlopcbWVOmrNRA792jXdYqNejh5+iR8OVz2CXwrY/xI7mX0= 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=v1zYh9YS; 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="v1zYh9YS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69FB51F000FF; Fri, 11 Sep 2026 05:15:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1789103747; bh=mgDaPY5xGFIw12DnWMtQLt5DSSz2wiVbrOeAMPCvYLE=; h=Date:To:From:Subject; b=v1zYh9YSJInuUe6db0zeTn/t8c5S2fm7lywUEOk8fFkuRVMcrYjIPxCTo3/wZk7Z6 8OcypI1PERg+H6WkV4X2wZHWwJJ2X8g+vAppA27UM5UYty3H0ScmifBNwe4+TpBOOu TdG0VPoYUbSGeMbc53uu82+MnntOE64XkCOuKnNs= Date: Thu, 10 Sep 2026 22:15:47 -0700 To: mm-commits@vger.kernel.org,songmuchun@bytedance.com,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-sparse-vmemmap-prepare-dax-vmemmap-population-for-compound-page-orders.patch added to mm-new branch Message-Id: <20260911051547.69FB51F000FF@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: prepare DAX vmemmap population for compound page orders has been added to the -mm mm-new branch. Its filename is mm-sparse-vmemmap-prepare-dax-vmemmap-population-for-compound-page-orders.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-prepare-dax-vmemmap-population-for-compound-page-orders.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: prepare DAX vmemmap population for compound page orders Date: Fri, 11 Sep 2026 13:02:21 +0800 Device DAX still uses vmemmap_populate_compound_pages() to populate its compound-page vmemmap mappings. That helper allocates the head and first tail vmemmap pages explicitly, then reuses the first tail page for the remaining tail page mappings. Device DAX is being moved to the section-based vmemmap optimization infrastructure, but it cannot switch to the generic section-based population path yet. Once a later patch records the DAX compound page order in section metadata, DAX head and first-tail PFNs can look optimizable to the generic helpers as well. Add a DAX-specific population flag for this transition. It keeps DAX head/first-tail allocations on the normal vmemmap allocation path, while preserving the existing page reference for reused DAX tail mappings. Link: https://lore.kernel.org/20260911050228.58884-5-songmuchun@bytedance.com Signed-off-by: Muchun Song Acked-by: Qi Zheng Cc: David Hildenbrand (Arm) 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 --- mm/sparse-vmemmap.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) --- a/mm/sparse-vmemmap.c~mm-sparse-vmemmap-prepare-dax-vmemmap-population-for-compound-page-orders +++ a/mm/sparse-vmemmap.c @@ -35,8 +35,8 @@ /* * Flags for vmemmap_populate_range and friends. */ -/* Get a ref on the head page struct page, for ZONE_DEVICE compound pages */ -#define VMEMMAP_POPULATE_PAGEREF 0x0001 +/* Vmemmap population for ZONE_DEVICE compound pages */ +#define VMEMMAP_POPULATE_DAX 0x0001 #include "internal.h" #include "mm_init.h" @@ -208,13 +208,17 @@ struct page __ref *vmemmap_shared_tail_p } static __meminit void *vmemmap_alloc_pte(unsigned long pfn, int node, - struct vmem_altmap *altmap) + struct vmem_altmap *altmap, unsigned long flags) { struct zone *zone; struct page *page; const unsigned int order = pfn_to_section_compound_order(pfn); - if (!vmemmap_optimizable_pfn(pfn)) + /* + * Device DAX still relies on vmemmap_populate_compound_pages() for + * head/first-tail allocation and tail-page reuse. + */ + if (!vmemmap_optimizable_pfn(pfn) || flags & VMEMMAP_POPULATE_DAX) return vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap); zone = pfn_to_zone(pfn, node); @@ -236,7 +240,7 @@ static pte_t * __meminit vmemmap_pte_pop pte_t entry; if (ptpfn == (unsigned long)-1) { - void *p = vmemmap_alloc_pte(pfn, node, altmap); + void *p = vmemmap_alloc_pte(pfn, node, altmap, flags); if (!p) return NULL; @@ -251,7 +255,7 @@ static pte_t * __meminit vmemmap_pte_pop * and through vmemmap_populate_compound_pages() when * slab is available. */ - if (flags & VMEMMAP_POPULATE_PAGEREF) + if (flags & VMEMMAP_POPULATE_DAX) get_page(pfn_to_page(ptpfn)); } entry = pfn_pte(ptpfn, PAGE_KERNEL); @@ -511,6 +515,7 @@ static int __meminit vmemmap_populate_co unsigned long size, addr; pte_t *pte; int rc; + unsigned long flags = VMEMMAP_POPULATE_DAX; if (reuse_compound_section(start_pfn, pgmap)) { pte = compound_section_tail_page(start); @@ -522,8 +527,7 @@ static int __meminit vmemmap_populate_co * with just tail struct pages. */ return vmemmap_populate_range(start, end, node, NULL, - pte_pfn(ptep_get(pte)), - VMEMMAP_POPULATE_PAGEREF); + pte_pfn(ptep_get(pte)), flags); } size = min(end - start, pgmap_vmemmap_nr(pgmap) * sizeof(struct page)); @@ -531,13 +535,13 @@ static int __meminit vmemmap_populate_co unsigned long next, last = addr + size; /* Populate the head page vmemmap page */ - pte = vmemmap_populate_address(addr, node, NULL, -1, 0); + pte = vmemmap_populate_address(addr, node, NULL, -1, flags); if (!pte) return -ENOMEM; /* Populate the tail pages vmemmap page */ next = addr + PAGE_SIZE; - pte = vmemmap_populate_address(next, node, NULL, -1, 0); + pte = vmemmap_populate_address(next, node, NULL, -1, flags); if (!pte) return -ENOMEM; @@ -547,8 +551,7 @@ static int __meminit vmemmap_populate_co */ next += PAGE_SIZE; rc = vmemmap_populate_range(next, last, node, NULL, - pte_pfn(ptep_get(pte)), - VMEMMAP_POPULATE_PAGEREF); + pte_pfn(ptep_get(pte)), flags); if (rc) return -ENOMEM; } _ 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