[PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[Xie Yuanbin]

Currently, memory-failure can be enabled without migration. However,
migration cannot be selected by user when memory-failure is enabled.

Migration is very useful for soft_offline_page(), which may be triggered
by correctable memory errors. Most of the anonymous or file-mapping
faulty pages can be migrated to other healthy pages.

Allow user to select MIGRATION if MEMORY_FAILURE is enabled.
Also, select MIGRATION by default if MEMORY_FAILURE is enabled.

Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
---
 mm/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 8a24c130d008..b4c217383b51 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -682,7 +682,8 @@ config NUMA_MIGRATION
 	  demotion for memory tiering.
 
 config MIGRATION
-	bool
+	bool "Enable page migration" if MEMORY_FAILURE	
+	default y if MEMORY_FAILURE
 	depends on MMU
 
 config DEVICE_MIGRATION
-- 
2.55.0

Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[Mike Rapoport]

Hi,

On Wed, Aug 12, 2026 at 05:16:44PM +0800, Xie Yuanbin wrote:
> Currently, memory-failure can be enabled without migration. However,
> migration cannot be selected by user when memory-failure is enabled.
> 
> Migration is very useful for soft_offline_page(), which may be triggered
> by correctable memory errors. Most of the anonymous or file-mapping
> faulty pages can be migrated to other healthy pages.
> 
> Allow user to select MIGRATION if MEMORY_FAILURE is enabled.
> Also, select MIGRATION by default if MEMORY_FAILURE is enabled.

Do we want to make users decide if they need MIGRATION when MEMORY_FAILURE
is enabled?

Just make MEMORY_FAILURE select MIGRATION.
 
> Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
> ---
>  mm/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 8a24c130d008..b4c217383b51 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -682,7 +682,8 @@ config NUMA_MIGRATION
>  	  demotion for memory tiering.
>  
>  config MIGRATION
> -	bool
> +	bool "Enable page migration" if MEMORY_FAILURE	
> +	default y if MEMORY_FAILURE
>  	depends on MMU
>  
>  config DEVICE_MIGRATION
> -- 
> 2.55.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[Lorenzo Stoakes (ARM)]

On Wed, Aug 12, 2026 at 01:45:30PM +0300, Mike Rapoport wrote:
> Hi,
>
> On Wed, Aug 12, 2026 at 05:16:44PM +0800, Xie Yuanbin wrote:
> > Currently, memory-failure can be enabled without migration. However,
> > migration cannot be selected by user when memory-failure is enabled.
> >
> > Migration is very useful for soft_offline_page(), which may be triggered
> > by correctable memory errors. Most of the anonymous or file-mapping
> > faulty pages can be migrated to other healthy pages.
> >
> > Allow user to select MIGRATION if MEMORY_FAILURE is enabled.
> > Also, select MIGRATION by default if MEMORY_FAILURE is enabled.
>
> Do we want to make users decide if they need MIGRATION when MEMORY_FAILURE
> is enabled?
>
> Just make MEMORY_FAILURE select MIGRATION.

NO.

Explain first why the hell one of the other options that selection migration
can't be enabled.

Changing configs just to support a weirdo no to compaction but yes to doing soft
offline for debugging or whatever isn't really convincing unless a real world,
sensible use case can be stated.

The kernel isn't there to allow you to have broken configs.

>
> > Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
> > ---
> >  mm/Kconfig | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 8a24c130d008..b4c217383b51 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -682,7 +682,8 @@ config NUMA_MIGRATION
> >  	  demotion for memory tiering.
> >
> >  config MIGRATION
> > -	bool
> > +	bool "Enable page migration" if MEMORY_FAILURE
> > +	default y if MEMORY_FAILURE
> >  	depends on MMU
> >
> >  config DEVICE_MIGRATION
> > --
> > 2.55.0
> >
>
> --
> Sincerely yours,
> Mike.

--
Cheers, Lorenzo

Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[Mike Rapoport]

On Wed, Aug 12, 2026 at 11:55:03AM +0100, Lorenzo Stoakes (ARM) wrote:
> On Wed, Aug 12, 2026 at 01:45:30PM +0300, Mike Rapoport wrote:
> > Hi,
> >
> > On Wed, Aug 12, 2026 at 05:16:44PM +0800, Xie Yuanbin wrote:
> > > Currently, memory-failure can be enabled without migration. However,
> > > migration cannot be selected by user when memory-failure is enabled.
> > >
> > > Migration is very useful for soft_offline_page(), which may be triggered
> > > by correctable memory errors. Most of the anonymous or file-mapping
> > > faulty pages can be migrated to other healthy pages.
> > >
> > > Allow user to select MIGRATION if MEMORY_FAILURE is enabled.
> > > Also, select MIGRATION by default if MEMORY_FAILURE is enabled.
> >
> > Do we want to make users decide if they need MIGRATION when MEMORY_FAILURE
> > is enabled?
> >
> > Just make MEMORY_FAILURE select MIGRATION.
> 
> NO.
> 
> Explain first why the hell one of the other options that selection migration
> can't be enabled.

Think small systems ;-P
 
> Changing configs just to support a weirdo no to compaction but yes to doing soft
> offline for debugging or whatever isn't really convincing unless a real world,
> sensible use case can be stated.
> 
> The kernel isn't there to allow you to have broken configs.
> 
> >
> > > Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
> > > ---
> > >  mm/Kconfig | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/Kconfig b/mm/Kconfig
> > > index 8a24c130d008..b4c217383b51 100644
> > > --- a/mm/Kconfig
> > > +++ b/mm/Kconfig
> > > @@ -682,7 +682,8 @@ config NUMA_MIGRATION
> > >  	  demotion for memory tiering.
> > >
> > >  config MIGRATION
> > > -	bool
> > > +	bool "Enable page migration" if MEMORY_FAILURE
> > > +	default y if MEMORY_FAILURE
> > >  	depends on MMU
> > >
> > >  config DEVICE_MIGRATION
> > > --
> > > 2.55.0
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> 
> --
> Cheers, Lorenzo

-- 
Sincerely yours,
Mike.

Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[Lorenzo Stoakes (ARM)]

On Wed, Aug 12, 2026 at 05:16:44PM +0800, Xie Yuanbin wrote:
> Currently, memory-failure can be enabled without migration. However,
> migration cannot be selected by user when memory-failure is enabled.

What?

CONFIG_MIGRATION isn't user-selectable is it? So nobody can select it? It's
enabled by other stuff. So this is just incorrect anyway.

But you seem to be implying the two options cannot both be enabled, that's
untrue:

$ grep CONFIG_MIGRATION .config
CONFIG_MIGRATION=y
$ grep CONFIG_MEMORY_FAILURE .config
CONFIG_MEMORY_FAILURE=y

Have you disabled compaction somehow?

It sounds like your .config is broken and... you need to fix it yourself not
edit mm/Kconfig?

If not you need to spell out exactly what config it is you have where you must
not have one of the things that select migration, but do want it anyway.

I'm not sure we'd even support that?

Right now:

	CONFIG_COMPACTION (!)
	CONFIG_MEMORY_HOTREMOVE
	CONFIG_NUMA_MIGRATION
	CONFIG_CMA

All select CONFIG_MIGRATION. Why is it that you cannot select one of these? What
weird config needs CONFIG_COMPACTION disabled but does want migration just for
soft offline debugging?

Yet again it feels like debug stuff like ends up being production stuff here...

>
> Migration is very useful for soft_offline_page(), which may be triggered
> by correctable memory errors. Most of the anonymous or file-mapping
> faulty pages can be migrated to other healthy pages.

OK, so now you're wanting to enable a core kernel feature just for the sake of a
debug feature?...

>
> Allow user to select MIGRATION if MEMORY_FAILURE is enabled.

Users shouldn't select this at all. And this is an absolutely horrible way of
resolving whatever your real configuration issue is.

> Also, select MIGRATION by default if MEMORY_FAILURE is enabled.

Why? You've not made a case for this at all.

Tell us what your config actually is instead of doing a hack please.

>
> Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
> ---
>  mm/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 8a24c130d008..b4c217383b51 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -682,7 +682,8 @@ config NUMA_MIGRATION
>  	  demotion for memory tiering.
>
>  config MIGRATION
> -	bool
> +	bool "Enable page migration" if MEMORY_FAILURE
> +	default y if MEMORY_FAILURE

I hate hate hate this. This is just completely the wrong resolution.


>  	depends on MMU
>
>  config DEVICE_MIGRATION
> --
> 2.55.0
>

--
Cheers, Lorenzo

Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[Xie Yuanbin]

On Wed, 12 Aug 2026 11:53:29 +0100, Lorenzo Stoakes (ARM) wrote:
> But you seem to be implying the two options cannot both be enabled, that's
> untrue:
>
> $ grep CONFIG_MIGRATION .config
> CONFIG_MIGRATION=y
> $ grep CONFIG_MEMORY_FAILURE .config
> CONFIG_MEMORY_FAILURE=y
>
> Have you disabled compaction somehow?
>
> It sounds like your .config is broken and... you need to fix it yourself not
> edit mm/Kconfig?
>
> If not you need to spell out exactly what config it is you have where you must
> not have one of the things that select migration, but do want it anyway.
>
> I'm not sure we'd even support that?
>
> Right now:
>
>	CONFIG_COMPACTION (!)
>	CONFIG_MEMORY_HOTREMOVE
>	CONFIG_NUMA_MIGRATION
>	CONFIG_CMA
>
> All select CONFIG_MIGRATION. Why is it that you cannot select one of these?

As you say, currently, MEMORY_FAILURE and MIGRATION can be both
enabled, however, you must enable one of the following configs
at the same time:
	CONFIG_COMPACTION
	CONFIG_MEMORY_HOTREMOVE
	CONFIG_NUMA_MIGRATION
	CONFIG_CMA

However, for embedded devices, these configs are not always enabled, and
they can indeed be manually disable. This is the actual situation I am
currently encountering.

> What
> weird config needs CONFIG_COMPACTION disabled but does want migration just for
> soft offline debugging?

It is not for debugging, but a real configuration in the production environment:
	CONFIG_COMPACTION=n
	CONFIG_MEMORY_HOTREMOVE=n
	CONFIG_NUMA=n
	CONFIG_CMA=n
	CONFIG_MEMORY_FAILURE=y

> Users shouldn't select this at all. And this is an absolutely horrible way of
> resolving whatever your real configuration issue is.
>
> I hate hate hate this. This is just completely the wrong resolution.

What abort making MEMORY_FAILURE select MIGRATION, just like what Mike
Rapoport said? If it's not appropriate no matter what, then let's stop
discussing this patch as if it was never submitted. I'm sorry about that.

Thanks very much.

Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled

[David Hildenbrand (Arm)]

On 8/12/26 11:16, Xie Yuanbin wrote:
> Currently, memory-failure can be enabled without migration. However,
> migration cannot be selected by user when memory-failure is enabled.
> 
> Migration is very useful for soft_offline_page(), which may be triggered
> by correctable memory errors. Most of the anonymous or file-mapping
> faulty pages can be migrated to other healthy pages.
> 
> Allow user to select MIGRATION if MEMORY_FAILURE is enabled.
> Also, select MIGRATION by default if MEMORY_FAILURE is enabled.
> 
> Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
> ---
>  mm/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 8a24c130d008..b4c217383b51 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -682,7 +682,8 @@ config NUMA_MIGRATION
>  	  demotion for memory tiering.
>  
>  config MIGRATION
> -	bool
> +	bool "Enable page migration" if MEMORY_FAILURE	
> +	default y if MEMORY_FAILURE
>  	depends on MMU

As others raised, don't make this user-selectable. If some other config requires
this, glue it to that config.

Don't make it harder for users to figure out which mechanism A needs mechanism B
to be useful :)

-- 
Cheers,

David