From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Xie Yuanbin <xieyuanbin1@huawei.com>
Cc: david@kernel.org, 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, rppt@kernel.org,
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 10:32:20 +0100 [thread overview]
Message-ID: <an2PGVZuYruQhzel@lucifer> (raw)
In-Reply-To: <20260813092343.214324-1-xieyuanbin1@huawei.com>
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
next prev parent reply other threads:[~2026-08-13 9:32 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)
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) [this message]
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=an2PGVZuYruQhzel@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bp@alien8.de \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--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=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.