From: Frank van der Linden <fvdl@google.com>
To: akpm@linux-foundation.org, muchun.song@linux.dev, linux-mm@kvack.org
Cc: yuzhao@google.com, usamaarif642@gmail.com,
joao.m.martins@oracle.com, roman.gushchin@linux.dev,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH mm-unstable] mm: make SPARSEMEM_VMEMMAP_PREINIT an internal option
Date: Thu, 27 Feb 2025 11:07:05 -0800 [thread overview]
Message-ID: <CAPTztWbUdyMgBWFk8g5_sRaEy1q-EtOBvKzZZ7oaAz9iJv9kaQ@mail.gmail.com> (raw)
In-Reply-To: <20250227185717.1265644-1-fvdl@google.com>
On Thu, Feb 27, 2025 at 10:57 AM Frank van der Linden <fvdl@google.com> wrote:
>
> 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.
>
> Fixes: a916062fdd134 ("mm/sparse: allow for alternate vmemmap section init at boot")
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Signed-off-by: Frank van der Linden <fvdl@google.com>
> ---
> arch/x86/Kconfig | 2 +-
> fs/Kconfig | 1 +
> mm/Kconfig | 9 ++++-----
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 541347a6fa81..d05f26e301a9 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -147,7 +147,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_SPARSEMEM_VMEMMAP_PREINIT 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
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 64d420e3c475..8bcd3a6f80ab 100644
> --- a/fs/Kconfig
> +++ b/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
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 2761098dbc1a..7262a145ed64 100644
> --- a/mm/Kconfig
> +++ b/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
>
> --
> 2.48.1.711.g2feabab25a-goog
>
Hm, this should actually be split in two patches, since the x86 change
comes in a later patch in the original series.
Let me resend this in a v2 that contains two separate patches.
Sorry about the noise.
- Frank
next prev parent reply other threads:[~2025-02-27 19:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 18:57 Frank van der Linden
2025-02-27 19:07 ` Frank van der Linden [this message]
2025-02-27 19:12 ` Frank van der Linden
2025-02-27 19:52 ` Johannes Weiner
2025-02-28 0:12 ` Andrew Morton
2025-02-28 16:44 ` Frank van der Linden
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=CAPTztWbUdyMgBWFk8g5_sRaEy1q-EtOBvKzZZ7oaAz9iJv9kaQ@mail.gmail.com \
--to=fvdl@google.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=joao.m.martins@oracle.com \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=usamaarif642@gmail.com \
--cc=yuzhao@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox