All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,hannes@cmpxchg.org,fvdl@google.com,akpm@linux-foundation.org
Subject: + mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot-fix.patch added to mm-unstable branch
Date: Thu, 27 Feb 2025 14:29:28 -0800	[thread overview]
Message-ID: <20250227222928.DFE41C4CEDD@smtp.kernel.org> (raw)


The patch titled
     Subject: mm: make SPARSEMEM_VMEMMAP_PREINIT an internal option
has been added to the -mm mm-unstable branch.  Its filename is
     mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot-fix.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot-fix.patch

This patch will later appear in the mm-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

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 the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days

------------------------------------------------------
From: Frank van der Linden <fvdl@google.com>
Subject: mm: make SPARSEMEM_VMEMMAP_PREINIT an internal option
Date: Thu, 27 Feb 2025 18:57:17 +0000

SPARSEMEM_VMEMMAP_PREINIT is not useful as a user-facing option, it is
just something that should be selected if a subsystem wishes to do vmemmap
preinit.  That's currently only HUGETLB_PAGE_OPTIMIZE_VMEMMAP.

So, make it a default-less option that is only selected by
HUGETLB_PAGE_OPTIMIZE_VMEMMAP, iff the architecture has noted it is
capable of doing hugetlb vmemmap preinit.  That is done via
ARCH_WANT_HUGETLB_VMEMMAP_PREINIT, renamed from
ARCH_WANT_SPARSE_VMEMMAP_PREINIT.

Link: https://lkml.kernel.org/r/20250227185717.1265644-1-fvdl@google.com
Fixes: a916062fdd134 ("mm/sparse: allow for alternate vmemmap section init at boot")
Signed-off-by: Frank van der Linden <fvdl@google.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/x86/Kconfig |    1 +
 fs/Kconfig       |    1 +
 mm/Kconfig       |    9 ++++-----
 3 files changed, 6 insertions(+), 5 deletions(-)

--- a/arch/x86/Kconfig~mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot-fix
+++ a/arch/x86/Kconfig
@@ -146,6 +146,7 @@ config X86
 	select ARCH_WANT_LD_ORPHAN_WARN
 	select ARCH_WANT_OPTIMIZE_DAX_VMEMMAP	if X86_64
 	select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP	if X86_64
+	select ARCH_WANT_HUGETLB_VMEMMAP_PREINIT if X86_64
 	select ARCH_WANTS_THP_SWAP		if X86_64
 	select ARCH_HAS_PARANOID_L1D_FLUSH
 	select BUILDTIME_TABLE_SORT
--- a/fs/Kconfig~mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot-fix
+++ a/fs/Kconfig
@@ -286,6 +286,7 @@ config HUGETLB_PAGE_OPTIMIZE_VMEMMAP
 	def_bool HUGETLB_PAGE
 	depends on ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
 	depends on SPARSEMEM_VMEMMAP
+	select SPARSEMEM_VMEMMAP_PREINIT if ARCH_WANT_HUGETLB_VMEMMAP_PREINIT
 
 config HUGETLB_PMD_PAGE_TABLE_SHARING
 	def_bool HUGETLB_PAGE
--- a/mm/Kconfig~mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot-fix
+++ a/mm/Kconfig
@@ -443,13 +443,9 @@ config SPARSEMEM_VMEMMAP
 	  pfn_to_page and page_to_pfn operations.  This is the most
 	  efficient option when sufficient kernel resources are available.
 
-config ARCH_WANT_SPARSEMEM_VMEMMAP_PREINIT
+config SPARSEMEM_VMEMMAP_PREINIT
 	bool
 
-config SPARSEMEM_VMEMMAP_PREINIT
-	bool "Early init of sparse memory virtual memmap"
-	depends on SPARSEMEM_VMEMMAP && ARCH_WANT_SPARSEMEM_VMEMMAP_PREINIT
-	default y
 #
 # Select this config option from the architecture Kconfig, if it is preferred
 # to enable the feature of HugeTLB/dev_dax vmemmap optimization.
@@ -460,6 +456,9 @@ config ARCH_WANT_OPTIMIZE_DAX_VMEMMAP
 config ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
 	bool
 
+config ARCH_WANT_HUGETLB_VMEMMAP_PREINIT
+	bool
+
 config HAVE_MEMBLOCK_PHYS_MAP
 	bool
 
_

Patches currently in -mm which might be from fvdl@google.com are

mm-cma-export-total-and-free-number-of-pages-for-cma-areas.patch
mm-cma-support-multiple-contiguous-ranges-if-requested.patch
mm-cma-introduce-cma_intersects-function.patch
mm-hugetlb-use-cma_declare_contiguous_multi.patch
mm-hugetlb-remove-redundant-__clearpagereserved.patch
mm-hugetlb-use-online-nodes-for-bootmem-allocation.patch
mm-hugetlb-convert-cmdline-parameters-from-setup-to-early.patch
x86-mm-make-register_page_bootmem_memmap-handle-pte-mappings.patch
mm-bootmem_info-export-register_page_bootmem_memmap.patch
mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot.patch
mm-sparse-allow-for-alternate-vmemmap-section-init-at-boot-fix.patch
mm-hugetlb-set-migratetype-for-bootmem-folios.patch
mm-define-__init_reserved_page_zone-function.patch
mm-hugetlb-check-bootmem-pages-for-zone-intersections.patch
mm-sparse-add-vmemmap__hvo-functions.patch
mm-hugetlb-deal-with-multiple-calls-to-hugetlb_bootmem_alloc.patch
mm-hugetlb-move-huge_boot_pages-list-init-to-hugetlb_bootmem_alloc.patch
mm-hugetlb-add-pre-hvo-framework.patch
mm-hugetlb_vmemmap-fix-hugetlb_vmemmap_restore_folios-definition.patch
mm-hugetlb-do-pre-hvo-for-bootmem-allocated-pages.patch
x86-setup-call-hugetlb_bootmem_alloc-early.patch
x86-mm-set-arch_want_sparsemem_vmemmap_preinit.patch
mm-cma-simplify-zone-intersection-check.patch
mm-cma-introduce-a-cma-validate-function.patch
mm-cma-introduce-interface-for-early-reservations.patch
mm-hugetlb-add-hugetlb_cma_only-cmdline-option.patch
mm-hugetlb-enable-bootmem-allocation-from-cma-areas.patch
mm-hugetlb-move-hugetlb-cma-code-in-to-its-own-file.patch


                 reply	other threads:[~2025-02-27 22:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250227222928.DFE41C4CEDD@smtp.kernel.org \
    --to=akpm@linux-foundation.org \
    --cc=fvdl@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=mm-commits@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.