Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Xie Yuanbin <xieyuanbin1@huawei.com>
Cc: akpm@linux-foundation.org, david@kernel.org,
	linmiaohe@huawei.com,  ziy@nvidia.com, matthew.brost@intel.com,
	joshua.hahnjy@gmail.com,  rakie.kim@sk.com, byungchul@sk.com,
	ying.huang@linux.alibaba.com,  apopple@nvidia.com,
	nao.horiguchi@gmail.com, liam@infradead.org, vbabka@kernel.org,
	 rppt@kernel.org, surenb@google.com, mhocko@suse.com,
	gourry@gourry.net,  tony.luck@intel.com, bp@alien8.de,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	 liaohua4@huawei.com, lilinjie8@huawei.com
Subject: Re: [PATCH] mm/Kconfig: allow user to select MIGRATION if MEMORY_FAILURE is enabled
Date: Wed, 12 Aug 2026 11:53:29 +0100	[thread overview]
Message-ID: <anxOOiuSIL6tjufA@lucifer> (raw)
In-Reply-To: <20260812091644.224299-1-xieyuanbin1@huawei.com>

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


  parent reply	other threads:[~2026-08-12 10:53 UTC|newest]

Thread overview: 7+ 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-12 10:53 ` Lorenzo Stoakes (ARM) [this message]
2026-08-12 11:55   ` Xie Yuanbin
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=anxOOiuSIL6tjufA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox