From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Xie Yuanbin <xieyuanbin1@huawei.com>
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, ljs@kernel.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 11:11:11 +0200 [thread overview]
Message-ID: <837c2e83-ad5f-42f5-afef-5132e02fc19a@kernel.org> (raw)
In-Reply-To: <20260813072344.112797-1-xieyuanbin1@huawei.com>
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
next prev parent reply other threads:[~2026-08-13 9:11 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) [this message]
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=837c2e83-ad5f-42f5-afef-5132e02fc19a@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.