From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Xie Yuanbin <xieyuanbin1@huawei.com>, rppt@kernel.org, ljs@kernel.org
Cc: akpm@linux-foundation.org, apopple@nvidia.com, bp@alien8.de,
byungchul@sk.com, gourry@gourry.net, joshua.hahnjy@gmail.com,
liam@infradead.org, liaohua4@huawei.com, lilinjie8@huawei.com,
linmiaohe@huawei.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, matthew.brost@intel.com, mhocko@suse.com,
nao.horiguchi@gmail.com, rakie.kim@sk.com, surenb@google.com,
tony.luck@intel.com, vbabka@kernel.org,
ying.huang@linux.alibaba.com, ziy@nvidia.com
Subject: Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled
Date: Thu, 13 Aug 2026 09:06:07 +0200 [thread overview]
Message-ID: <0dc4a8da-b2e1-4eaf-bea7-070b38d6952c@kernel.org> (raw)
In-Reply-To: <20260813022616.9050-1-xieyuanbin1@huawei.com>
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
next prev parent reply other threads:[~2026-08-13 7:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 9:16 [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled Xie Yuanbin
2026-08-12 10:45 ` Mike Rapoport
2026-08-12 10:55 ` Lorenzo Stoakes (ARM)
2026-08-12 13:32 ` Mike Rapoport
2026-08-13 9:25 ` Lorenzo Stoakes (ARM)
2026-08-13 9:31 ` Lorenzo Stoakes (ARM)
2026-08-13 2:26 ` Xie Yuanbin
2026-08-13 7:06 ` David Hildenbrand (Arm) [this message]
2026-08-13 7:23 ` Xie Yuanbin
2026-08-13 9:11 ` David Hildenbrand (Arm)
2026-08-13 9:23 ` Xie Yuanbin
2026-08-13 9:32 ` Lorenzo Stoakes (ARM)
2026-08-13 12:14 ` Miaohe Lin
2026-08-12 10:53 ` Lorenzo Stoakes (ARM)
2026-08-12 11:55 ` Xie Yuanbin
2026-08-13 9:31 ` Lorenzo Stoakes (ARM)
2026-08-12 10:58 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0dc4a8da-b2e1-4eaf-bea7-070b38d6952c@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bp@alien8.de \
--cc=byungchul@sk.com \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=liam@infradead.org \
--cc=liaohua4@huawei.com \
--cc=lilinjie8@huawei.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=nao.horiguchi@gmail.com \
--cc=rakie.kim@sk.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=tony.luck@intel.com \
--cc=vbabka@kernel.org \
--cc=xieyuanbin1@huawei.com \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.