[PATCH 0/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE and cleanup CONFIG_MIGRATION

[PATCH 0/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE and cleanup CONFIG_MIGRATION

[David Hildenbrand (Arm)]

While working on memory hotplug code cleanups, I realized that
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE is not really required anymore.

Changing that revealed some rather nasty looking CONFIG_MIGRATION
handling.

Let's clean that up by introducing a dedicated CONFIG_NUMA_MIGRATION
option and reducing the dependencies that CONFIG_MIGRATION has.

Heavily cross compiled. I assume these changes are fine, but messing
with kconfig sometimes feels like playing with fire :)

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
David Hildenbrand (Arm) (2):
      mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE
      mm: introduce CONFIG_NUMA_MIGRATION and simplify CONFIG_MIGRATION

 arch/arm64/Kconfig           |  1 -
 arch/loongarch/Kconfig       |  1 -
 arch/powerpc/Kconfig         |  1 -
 arch/riscv/Kconfig           |  1 -
 arch/s390/Kconfig            |  1 -
 arch/x86/Kconfig             |  1 -
 include/linux/memory-tiers.h |  2 +-
 init/Kconfig                 |  2 +-
 mm/Kconfig                   | 33 +++++++++++++++------------------
 mm/memory-tiers.c            | 12 ++++++------
 mm/mempolicy.c               |  2 +-
 mm/migrate.c                 |  5 ++---
 12 files changed, 26 insertions(+), 36 deletions(-)
---
base-commit: fbf55982f31ae6aa11f890c36bccc130ce70a312
change-id: 20260317-config_migration-463e20400499

Best regards,
-- 
David Hildenbrand (Arm) <david@kernel.org>

[PATCH 1/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE

[David Hildenbrand (Arm)]

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(-)

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

[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

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

[David Hildenbrand (Arm)]

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(-)

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

[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

Re: [PATCH 0/2] mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE and cleanup CONFIG_MIGRATION

[Jonathan Cameron]

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

> While working on memory hotplug code cleanups, I realized that
> CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE is not really required anymore.
> 
> Changing that revealed some rather nasty looking CONFIG_MIGRATION
> handling.
> 
> Let's clean that up by introducing a dedicated CONFIG_NUMA_MIGRATION
> option and reducing the dependencies that CONFIG_MIGRATION has.
> 
> Heavily cross compiled. I assume these changes are fine, but messing
> with kconfig sometimes feels like playing with fire :)
Seems fine to me, but I agree it always feels a bit like playing with fire.
So more eyes good!

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>

> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
> David Hildenbrand (Arm) (2):
>       mm: remove CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE
>       mm: introduce CONFIG_NUMA_MIGRATION and simplify CONFIG_MIGRATION
> 
>  arch/arm64/Kconfig           |  1 -
>  arch/loongarch/Kconfig       |  1 -
>  arch/powerpc/Kconfig         |  1 -
>  arch/riscv/Kconfig           |  1 -
>  arch/s390/Kconfig            |  1 -
>  arch/x86/Kconfig             |  1 -
>  include/linux/memory-tiers.h |  2 +-
>  init/Kconfig                 |  2 +-
>  mm/Kconfig                   | 33 +++++++++++++++------------------
>  mm/memory-tiers.c            | 12 ++++++------
>  mm/mempolicy.c               |  2 +-
>  mm/migrate.c                 |  5 ++---
>  12 files changed, 26 insertions(+), 36 deletions(-)
> ---
> base-commit: fbf55982f31ae6aa11f890c36bccc130ce70a312
> change-id: 20260317-config_migration-463e20400499
> 
> Best regards,