mm/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
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.0On 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
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
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.
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
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.
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?
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
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.
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
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.
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
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 > . >
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
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.
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
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
© 2016 - 2026 Red Hat, Inc.