On Thu, Feb 27, 2025 at 11:07 AM Frank van der Linden <fvdl@xxxxxxxxxx> wrote:
>
> On Thu, Feb 27, 2025 at 10:57 AM Frank van der Linden <fvdl@xxxxxxxxxx> 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@xxxxxxxxxxx>
> > Signed-off-by: Frank van der Linden <fvdl@xxxxxxxxxx>
> > ---
> > 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
Actually, sending two fixes would make mm-unstable not bisectable.
I'll just leave it at this one. If I send a v5 at some point, I can
change the two commits individually.
- Frank
