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 595E14483A5 for ; Tue, 29 Sep 2026 21:32:41 +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=1790717563; cv=none; b=DcAIJALbM01poVRPaUSVP5UabhaRZw1Alsb6aPaJ0tZTri7WMz8Aj8W1XvI7n7g5DM02ssgQ86YfUBuROiF5s36HVPWioOhhqwRedKJVUfnBnpi8sd6JRGr5aeAWywEOLeDdD8aEyLIVYp3K5h3f+D603U9hv7X/tUoAFUxo/pw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790717563; c=relaxed/simple; bh=BOcen2YAjpcfPmCZP6zDS0Vu7ml5K5fnkOCy/Q6qKVs=; h=Date:To:From:Subject:Message-Id; b=kBxqli5caZV3AYq/jL5oof0e2dvl+DYedR0Fma2myL39HWqkBbNwAljwKhvSSTT6VzONOmDGK/yXMEobPw6BH2djFurDcUcIpVqluv1tKfrLi6g2AeU8uru5KdY5vfwoeHAlvEMbdMo7O2zGl1eOnJGiGimLzXMG1cjnL12dEG0= 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=S8/OWHX+; 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="S8/OWHX+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0B5E1F000FF; Tue, 29 Sep 2026 21:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1790717559; bh=9hiyhtPQQ19azZZSVjk9jLBOUDE1E7bcpYfiXb7KYdE=; h=Date:To:From:Subject; b=S8/OWHX+S3UYVR4E3D/7E3h+j2M0eu+TALABrYjNMo+QZ6Rw4ouFyJ19nHW08J9sb 9kkzPSYXo/eZP8REeoRgJIEF80uDwq9uf4lWIGs5cP/LKO/B+6uJ9F58tOVkmxhKR1 +bo2iNEHa/veRi7lUPfKNA6183WrWfqqNWI7GKxg= Date: Tue, 29 Sep 2026 14:32:39 -0700 To: mm-commits@vger.kernel.org,muchun.song@linux.dev,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-sparse-vmemmap-drop-device-dax-specific-population-path.patch added to mm-new branch Message-Id: <20260929213239.A0B5E1F000FF@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: drop Device DAX-specific population path has been added to the -mm mm-new branch. Its filename is mm-sparse-vmemmap-drop-device-dax-specific-population-path.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-drop-device-dax-specific-population-path.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: drop Device DAX-specific population path Date: Tue, 29 Sep 2026 13:32:28 +0800 The common vmemmap path selects the shared page for optimized mappings itself, so Device DAX no longer needs vmemmap_populate_compound_pages() to find a shared tail page and pass its backing PFN through the generic population helpers. Remove the Device DAX-specific population path and let section memmap population always use vmemmap_populate(). The powerpc retains an architecture-specific compound-page implementation, so select it directly from radix__vmemmap_populate() for optimizable sections. Link: https://lore.kernel.org/20260929053231.66085-4-songmuchun@bytedance.com Signed-off-by: Muchun Song Signed-off-by: Andrew Morton Acked-by: Qi Zheng Cc: Madhavan Srinivasan Cc: Mike Rapoport Cc: David Hildenbrand Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Ritesh Harjani (IBM) Cc: Shrikanth Hegde Cc: Lorenzo Stoakes Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Suren Baghdasaryan Cc: Michal Hocko --- arch/powerpc/mm/book3s64/radix_pgtable.c | 3 mm/mm_init.c | 2 mm/sparse-vmemmap.c | 71 --------------------- 3 files changed, 5 insertions(+), 71 deletions(-) --- a/arch/powerpc/mm/book3s64/radix_pgtable.c~mm-sparse-vmemmap-drop-device-dax-specific-population-path +++ a/arch/powerpc/mm/book3s64/radix_pgtable.c @@ -1122,7 +1122,10 @@ int __meminit radix__vmemmap_populate(un pud_t *pud; pmd_t *pmd; pte_t *pte; + unsigned long pfn = page_to_pfn((struct page *)start); + if (vmemmap_optimizable_order(pfn_to_section_compound_order(pfn))) + return vmemmap_populate_compound_pages(pfn, start, end, node, NULL); /* * If altmap is present, Make sure we align the start vmemmap addr * to PAGE_SIZE so that we calculate the correct start_pfn in --- a/mm/mm_init.c~mm-sparse-vmemmap-drop-device-dax-specific-population-path +++ a/mm/mm_init.c @@ -1046,7 +1046,7 @@ static void zone_device_page_init_from_t * initialize is a lot smaller that the total amount of struct pages being * mapped. This is a paired / mild layering violation with explicit knowledge * of how the sparse_vmemmap internals handle compound pages in the lack - * of an altmap. See vmemmap_populate_compound_pages(). + * of an altmap. */ static inline unsigned long compound_nr_pages(unsigned long pfn, struct dev_pagemap *pgmap) --- a/mm/sparse-vmemmap.c~mm-sparse-vmemmap-drop-device-dax-specific-population-path +++ a/mm/sparse-vmemmap.c @@ -499,71 +499,6 @@ int __meminit vmemmap_populate_hugepages return 0; } -#ifndef vmemmap_populate_compound_pages -/* - * For compound pages bigger than section size (e.g. x86 1G compound - * pages with 2M subsection size) fill the rest of sections as tail - * pages. - * - * Note that memremap_pages() resets @nr_range value and will increment - * it after each range successful onlining. Thus the value or @nr_range - * at section memmap populate corresponds to the in-progress range - * being onlined here. - */ -static bool __meminit reuse_compound_section(unsigned long start_pfn, - struct dev_pagemap *pgmap) -{ - unsigned long nr_pages = pgmap_vmemmap_nr(pgmap); - unsigned long offset = start_pfn - - PHYS_PFN(pgmap->ranges[pgmap->nr_range].start); - - return !IS_ALIGNED(offset, nr_pages) && nr_pages > PAGES_PER_SUBSECTION; -} - -static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn, - unsigned long start, - unsigned long end, int node, - struct dev_pagemap *pgmap) -{ - unsigned long size, addr; - pte_t *pte; - int rc; - struct page *page; - unsigned int order = pfn_to_section_compound_order(start_pfn); - - page = vmemmap_shared_tail_page(order, device_zone(node)); - if (!page) - return -ENOMEM; - - if (reuse_compound_section(start_pfn, pgmap)) - return vmemmap_populate_range(start, end, node, NULL, - page_to_pfn(page)); - - size = min(end - start, (1UL << order) * sizeof(struct page)); - for (addr = start; addr < end; addr += size) { - unsigned long next, last = addr + size; - - /* Populate the head page vmemmap page */ - pte = vmemmap_populate_address(addr, node, NULL, -1); - if (!pte) - return -ENOMEM; - - /* - * Reuse the shared page for the rest of tail pages - * See layout diagram in Documentation/mm/vmemmap_dedup.rst - */ - next = addr + PAGE_SIZE; - rc = vmemmap_populate_range(next, last, node, NULL, - page_to_pfn(page)); - if (rc) - return -ENOMEM; - } - - return 0; -} - -#endif - struct page * __meminit __populate_section_memmap(unsigned long pfn, unsigned long nr_pages, int nid, struct vmem_altmap *altmap, struct dev_pagemap *pgmap) @@ -576,11 +511,7 @@ struct page * __meminit __populate_secti !IS_ALIGNED(nr_pages, PAGES_PER_SUBSECTION))) return NULL; - if (pgmap && section_vmemmap_optimizable(__pfn_to_section(pfn))) - r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); - else - r = vmemmap_populate(start, end, nid, altmap); - + r = vmemmap_populate(start, end, nid, altmap); if (r < 0) return NULL; _ Patches currently in -mm which might be from muchun.song@linux.dev are mm-sparse-vmemmap-factor-out-shared-vmemmap-tail-page-allocation.patch mm-sparse-vmemmap-allocate-shared-tail-page-array-dynamically.patch mm-sparse-vmemmap-introduce-config_vmemmap_optimization.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-switch-device-dax-to-shared-tail-vmemmap-pages-fix.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 mm-sparse-vmemmap-drop-vmemmap_populate_dax.patch mm-sparse-vmemmap-support-device-dax-in-common-vmemmap-path.patch mm-sparse-vmemmap-drop-device-dax-specific-population-path.patch mm-sparse-vmemmap-remove-the-unused-ptpfn-argument.patch mm-sparse-vmemmap-open-code-vmemmap_populate_address.patch mm-mm_init-add-zone-mismatch-warning-during-page-init.patch