All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Xie Yuanbin <xieyuanbin1@huawei.com>
Cc: david@kernel.org, rppt@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,  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:31:15 +0100	[thread overview]
Message-ID: <an2Nt3Wi-WagS0xP@lucifer> (raw)
In-Reply-To: <20260812115529.247548-1-xieyuanbin1@huawei.com>

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


  reply	other threads:[~2026-08-13  9:31 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)
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) [this message]
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=an2Nt3Wi-WagS0xP@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.