Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Zi Yan]

On 19 Mar 2026, at 4:19, David Hildenbrand (Arm) wrote:

> All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
> select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
>
> For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
> and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
> CONFIG_CMA and CONFIG_COMPACTION already do).
>
> We'll clean up CONFIG_MIGRATION next.
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
>  arch/arm64/Kconfig     | 1 -
>  arch/loongarch/Kconfig | 1 -
>  arch/powerpc/Kconfig   | 1 -
>  arch/riscv/Kconfig     | 1 -
>  arch/s390/Kconfig      | 1 -
>  arch/x86/Kconfig       | 1 -
>  mm/Kconfig             | 9 +++------
>  7 files changed, 3 insertions(+), 12 deletions(-)
>
Makes sense to me.

Acked-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Lorenzo Stoakes (Oracle)]

On Thu, Mar 19, 2026 at 09:19:40AM +0100, David Hildenbrand (Arm) wrote:
> All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
> select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
>
> For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
> and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
> CONFIG_CMA and CONFIG_COMPACTION already do).

Makes sense!

>
> We'll clean up CONFIG_MIGRATION next.
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

LGTM, so:

Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

> ---
>  arch/arm64/Kconfig     | 1 -
>  arch/loongarch/Kconfig | 1 -
>  arch/powerpc/Kconfig   | 1 -
>  arch/riscv/Kconfig     | 1 -
>  arch/s390/Kconfig      | 1 -
>  arch/x86/Kconfig       | 1 -
>  mm/Kconfig             | 9 +++------
>  7 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 38dba5f7e4d2..bcd9f5bc66e2 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -16,7 +16,6 @@ config ARM64
>  	select ARCH_BINFMT_ELF_STATE
>  	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
>  	select ARCH_ENABLE_MEMORY_HOTPLUG
> -	select ARCH_ENABLE_MEMORY_HOTREMOVE
>  	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
>  	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
>  	select ARCH_HAS_CACHE_LINE_SIZE
> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index d211c6572b0a..dbf65ad512f1 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -12,7 +12,6 @@ config LOONGARCH
>  	select ARCH_NEEDS_DEFER_KASAN
>  	select ARCH_DISABLE_KASAN_INLINE
>  	select ARCH_ENABLE_MEMORY_HOTPLUG
> -	select ARCH_ENABLE_MEMORY_HOTREMOVE
>  	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
>  	select ARCH_HAS_ACPI_TABLE_UPGRADE	if ACPI
>  	select ARCH_HAS_CPU_FINALIZE_INIT
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index ad7a2fe63a2a..9f3417b75b2b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -126,7 +126,6 @@ config PPC
>  	select ARCH_DISABLE_KASAN_INLINE	if PPC_RADIX_MMU
>  	select ARCH_DMA_DEFAULT_COHERENT	if !NOT_COHERENT_CACHE
>  	select ARCH_ENABLE_MEMORY_HOTPLUG
> -	select ARCH_ENABLE_MEMORY_HOTREMOVE
>  	select ARCH_HAS_COPY_MC			if PPC64
>  	select ARCH_HAS_CURRENT_STACK_POINTER
>  	select ARCH_HAS_DEBUG_VIRTUAL
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 90c531e6abf5..61a9d8d3ea64 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -21,7 +21,6 @@ config RISCV
>  	select ARCH_DMA_DEFAULT_COHERENT
>  	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
>  	select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM_VMEMMAP
> -	select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
>  	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
>  	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
>  	select ARCH_HAS_BINFMT_FLAT
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index edc927d9e85a..d01800962d84 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -85,7 +85,6 @@ config S390
>  	select ARCH_32BIT_USTAT_F_TINODE
>  	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
>  	select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM
> -	select ARCH_ENABLE_MEMORY_HOTREMOVE
>  	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
>  	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
>  	select ARCH_HAS_CC_CAN_LINK
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e2df1b147184..c290fe363f27 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -69,7 +69,6 @@ config X86
>  	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
>  	select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION
>  	select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64
> -	select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
>  	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if (PGTABLE_LEVELS > 2) && (X86_64 || X86_PAE)
>  	select ARCH_ENABLE_THP_MIGRATION if X86_64 && TRANSPARENT_HUGEPAGE
>  	select ARCH_HAS_ACPI_TABLE_UPGRADE	if ACPI
> diff --git a/mm/Kconfig b/mm/Kconfig
> index c012944938a7..b2e21d873d3f 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -465,9 +465,6 @@ config HAVE_BOOTMEM_INFO_NODE
>  config ARCH_ENABLE_MEMORY_HOTPLUG
>  	bool
>
> -config ARCH_ENABLE_MEMORY_HOTREMOVE
> -	bool
> -
>  # eventually, we can have this option just 'select SPARSEMEM'
>  menuconfig MEMORY_HOTPLUG
>  	bool "Memory hotplug"
> @@ -540,8 +537,8 @@ endchoice
>  config MEMORY_HOTREMOVE
>  	bool "Allow for memory hot remove"
>  	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
> -	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
> -	depends on MIGRATION
> +	depends on MEMORY_HOTPLUG
> +	select MIGRATION
>
>  config MHP_MEMMAP_ON_MEMORY
>  	def_bool y
> @@ -636,7 +633,7 @@ config PAGE_REPORTING
>  config MIGRATION
>  	bool "Page migration"
>  	default y
> -	depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU
> +	depends on (NUMA || MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU
>  	help
>  	  Allows the migration of the physical location of pages of processes
>  	  while the virtual addresses are not changed. This is useful in
>
> --
> 2.43.0
>

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Joshua Hahn]

On Thu, 19 Mar 2026 09:19:40 +0100 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
> select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
> 
> For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
> and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
> CONFIG_CMA and CONFIG_COMPACTION already do).
> 
> We'll clean up CONFIG_MIGRATION next.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

Hello David,

Looks good to me : -) Thank you for the patch, I hope you have a great day!

Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Gregory Price]

On Thu, Mar 19, 2026 at 09:19:40AM +0100, David Hildenbrand (Arm) wrote:
> All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
> select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
> 
> For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
> and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
> CONFIG_CMA and CONFIG_COMPACTION already do).
> 
> We'll clean up CONFIG_MIGRATION next.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

HOTREMOVE has long been a thorn in my side, I appreciate you cleaning
this up.

Reviewed-by: Gregory Price <gourry@gourry.net>

~Gregory

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Lorenzo Stoakes (Oracle)]

On Thu, Mar 19, 2026 at 11:24:27AM -0400, Gregory Price wrote:
> On Thu, Mar 19, 2026 at 09:19:40AM +0100, David Hildenbrand (Arm) wrote:
> > All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
> > select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
> > CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
> >
> > For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
> > and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
> > CONFIG_CMA and CONFIG_COMPACTION already do).
> >
> > We'll clean up CONFIG_MIGRATION next.
> >
> > Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>
> HOTREMOVE has long been a thorn in my side, I appreciate you cleaning
> this up.

That is quite the HOTTAKE young Gregory!

(It seems my pun crimes are continuing)

>
> Reviewed-by: Gregory Price <gourry@gourry.net>
>
> ~Gregory

Cheers, Lorenzo

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Gregory Price]

On Thu, Mar 19, 2026 at 04:34:04PM +0000, Lorenzo Stoakes (Oracle) wrote:
> On Thu, Mar 19, 2026 at 11:24:27AM -0400, Gregory Price wrote:
> > On Thu, Mar 19, 2026 at 09:19:40AM +0100, David Hildenbrand (Arm) wrote:
> > > All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
> > > select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
> > > CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
> > >
> > > For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
> > > and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
> > > CONFIG_CMA and CONFIG_COMPACTION already do).
> > >
> > > We'll clean up CONFIG_MIGRATION next.
> > >
> > > Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> >
> > HOTREMOVE has long been a thorn in my side, I appreciate you cleaning
> > this up.
> 
> That is quite the HOTTAKE young Gregory!
> 
> (It seems my pun crimes are continuing)
> 

:P - it's just more config cruft that always catches me cross-platform
when i poke around in dax and hotplug.  It'll be nice to get less
automated reports from CI lol

~Gregory

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[David Hildenbrand (Arm)]

On 3/19/26 16:24, Gregory Price wrote:
> On Thu, Mar 19, 2026 at 09:19:40AM +0100, David Hildenbrand (Arm) wrote:
>> All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
>> select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
>> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
>>
>> For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
>> and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
>> CONFIG_CMA and CONFIG_COMPACTION already do).
>>
>> We'll clean up CONFIG_MIGRATION next.
>>
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> 
> HOTREMOVE has long been a thorn in my side, I appreciate you cleaning
> this up.

On a long cardrive today I was wondering: do we still need a separate
MEMORY_HOTREMOVE

Now we'll have

config MEMORY_HOTREMOVE
	bool "Allow for memory hot remove"
	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
	depends on MEMORY_HOTPLUG
	select MIGRATION

I'll try to get rid of that HAVE_BOOTMEM_INFO_NODE shite next.

Then it's really just MIGRATION and some sprinkled
CONFIG_MEMORY_HOTREMOVE. Not a lot of code.

-- 
Cheers,

David

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Zi Yan]

On 19 Mar 2026, at 14:08, David Hildenbrand (Arm) wrote:

> On 3/19/26 16:24, Gregory Price wrote:
>> On Thu, Mar 19, 2026 at 09:19:40AM +0100, David Hildenbrand (Arm) wrote:
>>> All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
>>> select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
>>> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
>>>
>>> For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
>>> and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
>>> CONFIG_CMA and CONFIG_COMPACTION already do).
>>>
>>> We'll clean up CONFIG_MIGRATION next.
>>>
>>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>>
>> HOTREMOVE has long been a thorn in my side, I appreciate you cleaning
>> this up.
>
> On a long cardrive today I was wondering: do we still need a separate
> MEMORY_HOTREMOVE

You mean merge HOTREMOVE into HOTPLUG? I wondered the same. Is there
a reason to only have HOTPLUG without HOTREMOVE?

>
> Now we'll have
>
> config MEMORY_HOTREMOVE
> 	bool "Allow for memory hot remove"
> 	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
> 	depends on MEMORY_HOTPLUG
> 	select MIGRATION
>
> I'll try to get rid of that HAVE_BOOTMEM_INFO_NODE shite next.
>
> Then it's really just MIGRATION and some sprinkled
> CONFIG_MEMORY_HOTREMOVE. Not a lot of code.



Best Regards,
Yan, Zi

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[David Hildenbrand (Arm)]

On 3/19/26 19:12, Zi Yan wrote:
> On 19 Mar 2026, at 14:08, David Hildenbrand (Arm) wrote:
> 
>> On 3/19/26 16:24, Gregory Price wrote:
>>>
>>> HOTREMOVE has long been a thorn in my side, I appreciate you cleaning
>>> this up.
>>
>> On a long cardrive today I was wondering: do we still need a separate
>> MEMORY_HOTREMOVE
> 
> You mean merge HOTREMOVE into HOTPLUG?

Yes, only have a single config.

> I wondered the same. Is there
> a reason to only have HOTPLUG without HOTREMOVE?
In the past some architectures (e.g., s390x) did not support HOTREMOVE.
Then it made sense. I'm not sure if someone would want to build a kernel
with HOTPLUG but not have the bit of overhead for unplug+migration.

So I would guess nothing major speaks against it.

-- 
Cheers,

David

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Zi Yan]

On 19 Mar 2026, at 14:15, David Hildenbrand (Arm) wrote:

> On 3/19/26 19:12, Zi Yan wrote:
>> On 19 Mar 2026, at 14:08, David Hildenbrand (Arm) wrote:
>>
>>> On 3/19/26 16:24, Gregory Price wrote:
>>>>
>>>> HOTREMOVE has long been a thorn in my side, I appreciate you cleaning
>>>> this up.
>>>
>>> On a long cardrive today I was wondering: do we still need a separate
>>> MEMORY_HOTREMOVE
>>
>> You mean merge HOTREMOVE into HOTPLUG?
>
> Yes, only have a single config.
>
>> I wondered the same. Is there
>> a reason to only have HOTPLUG without HOTREMOVE?
> In the past some architectures (e.g., s390x) did not support HOTREMOVE.
> Then it made sense. I'm not sure if someone would want to build a kernel
> with HOTPLUG but not have the bit of overhead for unplug+migration.
>
> So I would guess nothing major speaks against it.

Sounds reasonable to me.

Best Regards,
Yan, Zi

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[Mike Rapoport]

On Thu, Mar 19, 2026 at 09:19:40AM +0100, David Hildenbrand (Arm) wrote:
> All architectures that select CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE also
> select CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG. So we can just remove
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE.
> 
> For CONFIG_MIGRATION, make it depend on CONFIG_MEMORY_HOTREMOVE instead,
> and make CONFIG_MEMORY_HOTREMOVE select CONFIG_MIGRATION (just like
> CONFIG_CMA and CONFIG_COMPACTION already do).
> 
> We'll clean up CONFIG_MIGRATION next.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
>  arch/arm64/Kconfig     | 1 -
>  arch/loongarch/Kconfig | 1 -
>  arch/powerpc/Kconfig   | 1 -
>  arch/riscv/Kconfig     | 1 -
>  arch/s390/Kconfig      | 1 -
>  arch/x86/Kconfig       | 1 -
>  mm/Kconfig             | 9 +++------
>  7 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index edc927d9e85a..d01800962d84 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -85,7 +85,6 @@ config S390
>  	select ARCH_32BIT_USTAT_F_TINODE
>  	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
>  	select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM

Not really related, but s390 does not have anything but SPARSEMEM_VMEMMAP.

> -	select ARCH_ENABLE_MEMORY_HOTREMOVE
>  	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
>  	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
>  	select ARCH_HAS_CC_CAN_LINK

-- 
Sincerely yours,
Mike.

Re: [PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[David Hildenbrand (Arm)]

>>  arch/arm64/Kconfig     | 1 -
>>  arch/loongarch/Kconfig | 1 -
>>  arch/powerpc/Kconfig   | 1 -
>>  arch/riscv/Kconfig     | 1 -
>>  arch/s390/Kconfig      | 1 -
>>  arch/x86/Kconfig       | 1 -
>>  mm/Kconfig             | 9 +++------
>>  7 files changed, 3 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index edc927d9e85a..d01800962d84 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -85,7 +85,6 @@ config S390
>>  	select ARCH_32BIT_USTAT_F_TINODE
>>  	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
>>  	select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM
> 
> Not really related, but s390 does not have anything but SPARSEMEM_VMEMMAP.

yeah, spotted that as well but decided to leave it as is for now.

Thanks!

-- 
Cheers,

David

Re: [PATCH 2/2] mm: introduce CONFIG_NUMA_MIGRATION and simplify CONFIG_MIGRATION

[Lorenzo Stoakes (Oracle)]

On Thu, Mar 19, 2026 at 09:19:41AM +0100, David Hildenbrand (Arm) wrote:
> CONFIG_MEMORY_HOTREMOVE, CONFIG_COMPACTION and CONFIG_CMA all select
> CONFIG_MIGRATION, because they require it to work (users).
>
> Only CONFIG_NUMA_BALANCING and CONFIG_BALLOON_MIGRATION depend on
> CONFIG_MIGRATION. CONFIG_BALLOON_MIGRATION is not an actual user, but
> an implementation of migration support, so the dependency is correct
> (CONFIG_BALLOON_MIGRATION does not make any sense without
> CONFIG_MIGRATION).
>
> However, kconfig-language.rst  clearly states "In general use select only
> for non-visible symbols". So far CONFIG_MIGRATION is user-visible ...
> and the dependencies rather confusing.
>
> The whole reason why CONFIG_MIGRATION is user-visible is because of
> CONFIG_NUMA: some users might want CONFIG_NUMA but not page migration
> support.
>
> Let's clean all that up by introducing a dedicated CONFIG_NUMA_MIGRATION
> config option for that purpose only. Make CONFIG_NUMA_BALANCING that so
> far depended on CONFIG_NUMA && CONFIG_MIGRATION to depend on
> CONFIG_MIGRATION instead. CONFIG_NUMA_MIGRATION will depend on
> CONFIG_NUMA && CONFIG_MMU.
>
> CONFIG_NUMA_MIGRATION is user-visible and will default to "y". We
> use that default so new configs will automatically enable it, just
> like it was the case with CONFIG_MIGRATION. The downside is that
> some configs that used to have CONFIG_MIGRATION=n might get it
> re-enabled by CONFIG_NUMA_MIGRATION=y, which shouldn't be a problem.
>
> CONFIG_MIGRATION is now a non-visible config option. Any code that
> select CONFIG_MIGRATION (as before) must depend directly or indirectly
> on CONFIG_MMU.

Nice. I always found it odd that it was optional.

>
> CONFIG_NUMA_MIGRATION is responsible for any NUMA migration code, which is
> mempolicy migration code, memory-tiering code, and move_pages() code in
> migrate.c. CONFIG_NUMA_BALANCING uses its functionality.
>
> Note that this implies that with CONFIG_NUMA_MIGRATION=n, move_pages() will
> not be available even though CONFIG_MIGRATION=y, which is an expected
> change.
>
> In migrate.c, we can remove the CONFIG_NUMA check as both
> CONFIG_NUMA_MIGRATION and CONFIG_NUMA_BALANCING depend on it.
>
> With this change, CONFIG_MIGRATION is an internal config, all users of
> migration selects CONFIG_MIGRATION, and only CONFIG_BALLOON_MIGRATION
> depends on it.
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

AFAICT this all LGTM, so:

Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

> ---
>  include/linux/memory-tiers.h |  2 +-
>  init/Kconfig                 |  2 +-
>  mm/Kconfig                   | 26 +++++++++++++-------------
>  mm/memory-tiers.c            | 12 ++++++------
>  mm/mempolicy.c               |  2 +-
>  mm/migrate.c                 |  5 ++---
>  6 files changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h
> index 96987d9d95a8..7999c58629ee 100644
> --- a/include/linux/memory-tiers.h
> +++ b/include/linux/memory-tiers.h
> @@ -52,7 +52,7 @@ int mt_perf_to_adistance(struct access_coordinate *perf, int *adist);
>  struct memory_dev_type *mt_find_alloc_memory_type(int adist,
>  						  struct list_head *memory_types);
>  void mt_put_memory_types(struct list_head *memory_types);
> -#ifdef CONFIG_MIGRATION
> +#ifdef CONFIG_NUMA_MIGRATION
>  int next_demotion_node(int node, const nodemask_t *allowed_mask);
>  void node_get_allowed_targets(pg_data_t *pgdat, nodemask_t *targets);
>  bool node_is_toptier(int node);
> diff --git a/init/Kconfig b/init/Kconfig
> index 444ce811ea67..3648e401b78b 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -997,7 +997,7 @@ config NUMA_BALANCING
>  	bool "Memory placement aware NUMA scheduler"
>  	depends on ARCH_SUPPORTS_NUMA_BALANCING
>  	depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
> -	depends on SMP && NUMA && MIGRATION && !PREEMPT_RT
> +	depends on SMP && NUMA_MIGRATION && !PREEMPT_RT
>  	help
>  	  This option adds support for automatic NUMA aware memory/task placement.
>  	  The mechanism is quite primitive and is based on migrating memory when
> diff --git a/mm/Kconfig b/mm/Kconfig
> index b2e21d873d3f..bd283958d675 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -627,20 +627,20 @@ config PAGE_REPORTING
>  	  those pages to another entity, such as a hypervisor, so that the
>  	  memory can be freed within the host for other uses.
>
> -#
> -# support for page migration
> -#
> -config MIGRATION
> -	bool "Page migration"
> +config NUMA_MIGRATION
> +	bool "NUMA page migration"
>  	default y
> -	depends on (NUMA || MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU
> -	help
> -	  Allows the migration of the physical location of pages of processes
> -	  while the virtual addresses are not changed. This is useful in
> -	  two situations. The first is on NUMA systems to put pages nearer
> -	  to the processors accessing. The second is when allocating huge
> -	  pages as migration can relocate pages to satisfy a huge page
> -	  allocation instead of reclaiming.
> +	depends on NUMA && MMU
> +	select MIGRATION
> +	help
> +	  Support the migration of pages to other NUMA nodes, available to
> +	  user space through interfaces like migrate_pages(), move_pages(),
> +	  and mbind(). Selecting this option also enables support for page
> +	  demotion for memory tiering.
> +
> +config MIGRATION
> +	bool
> +	depends on MMU
>
>  config DEVICE_MIGRATION
>  	def_bool MIGRATION && ZONE_DEVICE
> diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
> index 986f809376eb..54851d8a195b 100644
> --- a/mm/memory-tiers.c
> +++ b/mm/memory-tiers.c
> @@ -69,7 +69,7 @@ bool folio_use_access_time(struct folio *folio)
>  }
>  #endif
>
> -#ifdef CONFIG_MIGRATION
> +#ifdef CONFIG_NUMA_MIGRATION
>  static int top_tier_adistance;
>  /*
>   * node_demotion[] examples:
> @@ -129,7 +129,7 @@ static int top_tier_adistance;
>   *
>   */
>  static struct demotion_nodes *node_demotion __read_mostly;
> -#endif /* CONFIG_MIGRATION */
> +#endif /* CONFIG_NUMA_MIGRATION */
>
>  static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
>
> @@ -273,7 +273,7 @@ static struct memory_tier *__node_get_memory_tier(int node)
>  				     lockdep_is_held(&memory_tier_lock));
>  }
>
> -#ifdef CONFIG_MIGRATION
> +#ifdef CONFIG_NUMA_MIGRATION
>  bool node_is_toptier(int node)
>  {
>  	bool toptier;
> @@ -519,7 +519,7 @@ static void establish_demotion_targets(void)
>
>  #else
>  static inline void establish_demotion_targets(void) {}
> -#endif /* CONFIG_MIGRATION */
> +#endif /* CONFIG_NUMA_MIGRATION */
>
>  static inline void __init_node_memory_type(int node, struct memory_dev_type *memtype)
>  {
> @@ -911,7 +911,7 @@ static int __init memory_tier_init(void)
>  	if (ret)
>  		panic("%s() failed to register memory tier subsystem\n", __func__);
>
> -#ifdef CONFIG_MIGRATION
> +#ifdef CONFIG_NUMA_MIGRATION
>  	node_demotion = kzalloc_objs(struct demotion_nodes, nr_node_ids);
>  	WARN_ON(!node_demotion);
>  #endif
> @@ -938,7 +938,7 @@ subsys_initcall(memory_tier_init);
>
>  bool numa_demotion_enabled = false;
>
> -#ifdef CONFIG_MIGRATION
> +#ifdef CONFIG_NUMA_MIGRATION
>  #ifdef CONFIG_SYSFS
>  static ssize_t demotion_enabled_show(struct kobject *kobj,
>  				     struct kobj_attribute *attr, char *buf)
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index e5528c35bbb8..fd08771e2057 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1239,7 +1239,7 @@ static long do_get_mempolicy(int *policy, nodemask_t *nmask,
>  	return err;
>  }
>
> -#ifdef CONFIG_MIGRATION
> +#ifdef CONFIG_NUMA_MIGRATION
>  static bool migrate_folio_add(struct folio *folio, struct list_head *foliolist,
>  				unsigned long flags)
>  {
> diff --git a/mm/migrate.c b/mm/migrate.c
> index fdbb20163f66..05cb408846f2 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2224,8 +2224,7 @@ struct folio *alloc_migration_target(struct folio *src, unsigned long private)
>  	return __folio_alloc(gfp_mask, order, nid, mtc->nmask);
>  }
>
> -#ifdef CONFIG_NUMA
> -
> +#ifdef CONFIG_NUMA_MIGRATION
>  static int store_status(int __user *status, int start, int value, int nr)
>  {
>  	while (nr-- > 0) {
> @@ -2624,6 +2623,7 @@ SYSCALL_DEFINE6(move_pages, pid_t, pid, unsigned long, nr_pages,
>  {
>  	return kernel_move_pages(pid, nr_pages, pages, nodes, status, flags);
>  }
> +#endif /* CONFIG_NUMA_MIGRATION */
>
>  #ifdef CONFIG_NUMA_BALANCING
>  /*
> @@ -2766,4 +2766,3 @@ int migrate_misplaced_folio(struct folio *folio, int node)
>  	return nr_remaining ? -EAGAIN : 0;
>  }
>  #endif /* CONFIG_NUMA_BALANCING */
> -#endif /* CONFIG_NUMA */
>
> --
> 2.43.0
>

Re: [PATCH 2/2] mm: introduce CONFIG_NUMA_MIGRATION and simplify CONFIG_MIGRATION

[Zi Yan]

On 19 Mar 2026, at 4:19, David Hildenbrand (Arm) wrote:

> CONFIG_MEMORY_HOTREMOVE, CONFIG_COMPACTION and CONFIG_CMA all select
> CONFIG_MIGRATION, because they require it to work (users).
>
> Only CONFIG_NUMA_BALANCING and CONFIG_BALLOON_MIGRATION depend on
> CONFIG_MIGRATION. CONFIG_BALLOON_MIGRATION is not an actual user, but
> an implementation of migration support, so the dependency is correct
> (CONFIG_BALLOON_MIGRATION does not make any sense without
> CONFIG_MIGRATION).
>
> However, kconfig-language.rst  clearly states "In general use select only
> for non-visible symbols". So far CONFIG_MIGRATION is user-visible ...
> and the dependencies rather confusing.
>
> The whole reason why CONFIG_MIGRATION is user-visible is because of
> CONFIG_NUMA: some users might want CONFIG_NUMA but not page migration
> support.
>
> Let's clean all that up by introducing a dedicated CONFIG_NUMA_MIGRATION
> config option for that purpose only. Make CONFIG_NUMA_BALANCING that so
> far depended on CONFIG_NUMA && CONFIG_MIGRATION to depend on
> CONFIG_MIGRATION instead. CONFIG_NUMA_MIGRATION will depend on
> CONFIG_NUMA && CONFIG_MMU.
>
> CONFIG_NUMA_MIGRATION is user-visible and will default to "y". We
> use that default so new configs will automatically enable it, just
> like it was the case with CONFIG_MIGRATION. The downside is that
> some configs that used to have CONFIG_MIGRATION=n might get it
> re-enabled by CONFIG_NUMA_MIGRATION=y, which shouldn't be a problem.
>
> CONFIG_MIGRATION is now a non-visible config option. Any code that
> select CONFIG_MIGRATION (as before) must depend directly or indirectly
> on CONFIG_MMU.
>
> CONFIG_NUMA_MIGRATION is responsible for any NUMA migration code, which is
> mempolicy migration code, memory-tiering code, and move_pages() code in
> migrate.c. CONFIG_NUMA_BALANCING uses its functionality.
>
> Note that this implies that with CONFIG_NUMA_MIGRATION=n, move_pages() will
> not be available even though CONFIG_MIGRATION=y, which is an expected
> change.
>
> In migrate.c, we can remove the CONFIG_NUMA check as both
> CONFIG_NUMA_MIGRATION and CONFIG_NUMA_BALANCING depend on it.
>
> With this change, CONFIG_MIGRATION is an internal config, all users of
> migration selects CONFIG_MIGRATION, and only CONFIG_BALLOON_MIGRATION
> depends on it.
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
>  include/linux/memory-tiers.h |  2 +-
>  init/Kconfig                 |  2 +-
>  mm/Kconfig                   | 26 +++++++++++++-------------
>  mm/memory-tiers.c            | 12 ++++++------
>  mm/mempolicy.c               |  2 +-
>  mm/migrate.c                 |  5 ++---
>  6 files changed, 24 insertions(+), 25 deletions(-)
>
LGTM.

Acked-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi