[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 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

[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

[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

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

[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

[Xie Yuanbin]

On Wed, 12 Aug 2026 13:45:30 +0300, Mike Rapoport wrote:
> Do we want to make users decide if they need MIGRATION when MEMORY_FAILURE
> is enabled?
>
> Just make MEMORY_FAILURE select MIGRATION.

I agree with this solution, but I discovered another way: just like
commit 6ebf98d71f9b509e833e ("mm: introduce CONFIG_NUMA_MIGRATION and
simplify CONFIG_MIGRATION") done, add CONFIG_MEMORY_FAILURE_MIGRATION
to select MIGRATION. The Modification is also very simple:
```patch
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index a8b03e2920ba..500e54ace6c9 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1340,9 +1340,11 @@ static inline bool HWPoisonHandlable(struct page *page, unsigned long flags)
 	if (PageSlab(page))
 		return false;

+#ifdef CONFIG_MEMORY_FAILURE_MIGRATION
 	/* Soft offline could migrate movable_ops pages */
 	if ((flags & MF_SOFT_OFFLINE) && page_has_movable_ops(page))
 		return true;
+#endif

 	return PageLRU(page) || is_free_buddy_page(page);
 }
@@ -2028,7 +2030,8 @@ static int get_huge_page_for_hwpoison(unsigned long pfn, int flags,
 		count_increased = true;
 	} else if (folio_test_hugetlb_freed(folio)) {
 		ret = MF_HUGETLB_FREED;
-	} else if (folio_test_hugetlb_migratable(folio)) {
+	} else if (IS_ENABLED(CONFIG_MEMORY_FAILURE_MIGRATION) &&
+		   folio_test_hugetlb_migratable(folio)) {
 		if (folio_try_get(folio)) {
 			ret = MF_HUGETLB_IN_USED;
 			count_increased = true;
@@ -2051,10 +2054,12 @@ static int get_huge_page_for_hwpoison(unsigned long pfn, int flags,
 	 * Clearing hugetlb_migratable for hwpoisoned hugepages to prevent them
 	 * from being migrated by memory hotremove.
 	 */
+#ifdef CONFIG_MEMORY_FAILURE_MIGRATION
 	if (count_increased && folio_test_hugetlb_migratable(folio)) {
 		folio_clear_hugetlb_migratable(folio);
 		*migratable_cleared = true;
 	}
+#endif

 	spin_unlock_irq(&hugetlb_lock);
 	return ret;
@@ -2903,7 +2908,7 @@ static int soft_offline_in_use_page(struct page *page)
 		return 0;
 	}

-	isolated = isolate_folio_to_list(folio, &pagelist);
+	isolated = IS_ENABLED(CONFIG_MEMORY_FAILURE_MIGRATION) && isolate_folio_to_list(folio, &pagelist);

 	/*
 	 * If we succeed to isolate the folio, we grabbed another refcount on
```

Would this be a better way?

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

[David Hildenbrand (Arm)]

On 8/13/26 04:26, Xie Yuanbin wrote:
> On Wed, 12 Aug 2026 13:45:30 +0300, Mike Rapoport wrote:
>> Do we want to make users decide if they need MIGRATION when MEMORY_FAILURE
>> is enabled?
>>
>> Just make MEMORY_FAILURE select MIGRATION.
> 
> I agree with this solution, but I discovered another way: just like
> commit 6ebf98d71f9b509e833e ("mm: introduce CONFIG_NUMA_MIGRATION and
> simplify CONFIG_MIGRATION") done, add CONFIG_MEMORY_FAILURE_MIGRATION
> to select MIGRATION. The Modification is also very simple:
> ```patch
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index a8b03e2920ba..500e54ace6c9 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1340,9 +1340,11 @@ static inline bool HWPoisonHandlable(struct page *page, unsigned long flags)
>  	if (PageSlab(page))
>  		return false;
> 
> +#ifdef CONFIG_MEMORY_FAILURE_MIGRATION
>  	/* Soft offline could migrate movable_ops pages */
>  	if ((flags & MF_SOFT_OFFLINE) && page_has_movable_ops(page))
>  		return true;
> +#endif
> 
>  	return PageLRU(page) || is_free_buddy_page(page);
>  }
> @@ -2028,7 +2030,8 @@ static int get_huge_page_for_hwpoison(unsigned long pfn, int flags,
>  		count_increased = true;
>  	} else if (folio_test_hugetlb_freed(folio)) {
>  		ret = MF_HUGETLB_FREED;
> -	} else if (folio_test_hugetlb_migratable(folio)) {
> +	} else if (IS_ENABLED(CONFIG_MEMORY_FAILURE_MIGRATION) &&
> +		   folio_test_hugetlb_migratable(folio)) {
>  		if (folio_try_get(folio)) {
>  			ret = MF_HUGETLB_IN_USED;
>  			count_increased = true;
> @@ -2051,10 +2054,12 @@ static int get_huge_page_for_hwpoison(unsigned long pfn, int flags,
>  	 * Clearing hugetlb_migratable for hwpoisoned hugepages to prevent them
>  	 * from being migrated by memory hotremove.
>  	 */
> +#ifdef CONFIG_MEMORY_FAILURE_MIGRATION
>  	if (count_increased && folio_test_hugetlb_migratable(folio)) {
>  		folio_clear_hugetlb_migratable(folio);
>  		*migratable_cleared = true;
>  	}
> +#endif
> 
>  	spin_unlock_irq(&hugetlb_lock);
>  	return ret;
> @@ -2903,7 +2908,7 @@ static int soft_offline_in_use_page(struct page *page)
>  		return 0;
>  	}
> 
> -	isolated = isolate_folio_to_list(folio, &pagelist);
> +	isolated = IS_ENABLED(CONFIG_MEMORY_FAILURE_MIGRATION) && isolate_folio_to_list(folio, &pagelist);
> 
>  	/*
>  	 * If we succeed to isolate the folio, we grabbed another refcount on
> ```
> 
> Would this be a better way?

Why add a new config option?

-- 
Cheers,

David

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

[Xie Yuanbin]

On Thu, 13 Aug 2026 09:06:07 +0200, David Hildenbrand wrote:
> Why add a new config option?

I think this provides more flexibility in configuration, when:
	CONFIG_COMPACTION=n
	CONFIG_MEMORY_HOTREMOVE=n
	CONFIG_NUMA_MIGRATION=n
	CONFIG_CMA=n
	CONFIG_MEMORY_FAILURE=y
Users can choose whether to enable migration, just like what commit
6ebf98d71f9b509e833e ("mm: introduce CONFIG_NUMA_MIGRATION and simplify
CONFIG_MIGRATION") done. However, it does add a new config, which may
confuse the users...

I think that just making MEMORY_FAILURE select MIGRATION is also a very
good solution, and I respect the maintainers' opinion.

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

[David Hildenbrand (Arm)]

On 8/13/26 09:23, Xie Yuanbin wrote:
> On Thu, 13 Aug 2026 09:06:07 +0200, David Hildenbrand wrote:
>> Why add a new config option?
> 
> I think this provides more flexibility in configuration, when:
> 	CONFIG_COMPACTION=n
> 	CONFIG_MEMORY_HOTREMOVE=n
> 	CONFIG_NUMA_MIGRATION=n
> 	CONFIG_CMA=n
> 	CONFIG_MEMORY_FAILURE=y
> Users can choose whether to enable migration, just like what commit
> 6ebf98d71f9b509e833e ("mm: introduce CONFIG_NUMA_MIGRATION and simplify
> CONFIG_MIGRATION") done. However, it does add a new config, which may
> confuse the users...
> 
> I think that just making MEMORY_FAILURE select MIGRATION is also a very
> good solution, and I respect the maintainers' opinion.

There must be a good reason to do something fine grained like
MEMORY_FAILURE_MIGRATON, really.

So if there is a use case out there that absolutely doesn't want
CONFIG_MIGRATION but does want CONFIG_MEMORY_FAILURE, we could discuss it.

As really only softdirty needs page migration (IIRC), we could also just put
that under a separate config that implies CONFIG_MIGRATION, like
CONFIG_MEMORY_FAILURE_SOFT_OFFLINE. But I'd rather avoid that unless really
required.

-- 
Cheers,

David

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

[Xie Yuanbin]

Thanks for replying.

On Thu, 13 Aug 2026 11:11:11 +0200, David Hildenbrand wrote:
> On 8/13/26 09:23, Xie Yuanbin wrote:
>> I think that just making MEMORY_FAILURE select MIGRATION is also a very
>> good solution, and I respect the maintainers' opinion.
>
> There must be a good reason to do something fine grained like
> MEMORY_FAILURE_MIGRATON, really.
>
> So if there is a use case out there that absolutely doesn't want
> CONFIG_MIGRATION but does want CONFIG_MEMORY_FAILURE, we could discuss it.

At least so far, I haven't encountered such a use case.

> As really only softdirty needs page migration (IIRC), we could also just put
> that under a separate config that implies CONFIG_MIGRATION, like
> CONFIG_MEMORY_FAILURE_SOFT_OFFLINE. But I'd rather avoid that unless really
> required.

Okay, I understand it now. Making MEMORY_FAILURE select MIGRATION should
be enough.

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

[Lorenzo Stoakes (ARM)]

On Wed, Aug 12, 2026 at 04:32:12PM +0300, Mike Rapoport wrote:
> 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

That need soft offline and migration?...

--
Cheers, Lorenzo

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

[Lorenzo Stoakes (ARM)]

On Wed, Aug 12, 2026 at 07:55:29PM +0800, Xie Yuanbin wrote:
> 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.

Hmm really? It's a small embedded system that still needs to defragment for
large folios?

But...

>
> > 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.

...reality trumps theory, so if this is really a config you need, Mike's
approach seems the least worst way.

So respin with something that just adds a select CONFIG_MIGRATION there and
please put a description of your real world use case in the commit
message.

I doubt there are users who would find the combination problematic.

>
> Thanks very much.

--
Cheers, Lorenzo

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

[Lorenzo Stoakes (ARM)]

On Thu, Aug 13, 2026 at 10:26:04AM +0100, Lorenzo Stoakes (ARM) wrote:
> On Wed, Aug 12, 2026 at 04:32:12PM +0300, Mike Rapoport wrote:
> > 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
>
> That need soft offline and migration?...

But still, he did do what I asked and reality > theory so your suggestion seems
the least worst way.

>
> --
> Cheers, Lorenzo

--
Cheers, Lorenzo

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

[Lorenzo Stoakes (ARM)]

On Thu, Aug 13, 2026 at 05:23:43PM +0800, Xie Yuanbin wrote:
> Thanks for replying.
>
> On Thu, 13 Aug 2026 11:11:11 +0200, David Hildenbrand wrote:
> > On 8/13/26 09:23, Xie Yuanbin wrote:
> >> I think that just making MEMORY_FAILURE select MIGRATION is also a very
> >> good solution, and I respect the maintainers' opinion.
> >
> > There must be a good reason to do something fine grained like
> > MEMORY_FAILURE_MIGRATON, really.
> >
> > So if there is a use case out there that absolutely doesn't want
> > CONFIG_MIGRATION but does want CONFIG_MEMORY_FAILURE, we could discuss it.
>
> At least so far, I haven't encountered such a use case.
>
> > As really only softdirty needs page migration (IIRC), we could also just put
> > that under a separate config that implies CONFIG_MIGRATION, like
> > CONFIG_MEMORY_FAILURE_SOFT_OFFLINE. But I'd rather avoid that unless really
> > required.
>
> Okay, I understand it now. Making MEMORY_FAILURE select MIGRATION should
> be enough.

Agreed with all that David says, and yes that seems the best way.


--
Cheers, Lorenzo

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

[Miaohe Lin]

On 2026/8/13 17:32, Lorenzo Stoakes (ARM) wrote:
> On Thu, Aug 13, 2026 at 05:23:43PM +0800, Xie Yuanbin wrote:
>> Thanks for replying.
>>
>> On Thu, 13 Aug 2026 11:11:11 +0200, David Hildenbrand wrote:
>>> On 8/13/26 09:23, Xie Yuanbin wrote:
>>>> I think that just making MEMORY_FAILURE select MIGRATION is also a very
>>>> good solution, and I respect the maintainers' opinion.
>>>
>>> There must be a good reason to do something fine grained like
>>> MEMORY_FAILURE_MIGRATON, really.
>>>
>>> So if there is a use case out there that absolutely doesn't want
>>> CONFIG_MIGRATION but does want CONFIG_MEMORY_FAILURE, we could discuss it.
>>
>> At least so far, I haven't encountered such a use case.
>>
>>> As really only softdirty needs page migration (IIRC), we could also just put
>>> that under a separate config that implies CONFIG_MIGRATION, like
>>> CONFIG_MEMORY_FAILURE_SOFT_OFFLINE. But I'd rather avoid that unless really
>>> required.
>>
>> Okay, I understand it now. Making MEMORY_FAILURE select MIGRATION should
>> be enough.
> 
> Agreed with all that David says, and yes that seems the best way.

+1.

Thanks all.
.

> 
> 
> --
> Cheers, Lorenzo
> .
>