From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 37DB431353B for ; Wed, 12 Aug 2026 10:53:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786532033; cv=none; b=sAgDCWDmNpEkn89wiG3RKSfJCJXdqJN4SmzECYL5YNYr8hcCcVq0cluuuxepkPm8iMo4fzwbb+E97ZKEtT8pqMfA7pGUb2xpp652jOmx/gLjLDuVHNPeYs5rwYMw9TxjsDmrNOdlqx3qt+UsHwZ4n5cwbvAZftQnL0d91Lc/tiA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786532033; c=relaxed/simple; bh=1Ww7XXUo118WKMpAPAISqNJwY3W4friIPUDwAVWvwAo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KSX7/8hM+aR/aJjnI35XQXydIlLBpVYik8kI3I9GNQazgwpB9NCEYwqqcD2M41RoAE/xOqzUg5o5qkx03/VqWwZob9r7OQUerecaGdLqP1QQmSaenpg+LaRc0GphFijkAOOMWdDYh8SlwqpTkv5UqCqs9vefMIwpaqABzGJqcE4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aV1nBK8V; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aV1nBK8V" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7E711F000E9; Wed, 12 Aug 2026 10:53:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786532031; bh=Bhh9+ggGVZyLW6J616MkrfItqyn/uEre1JGJoPa70uo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aV1nBK8Vd3PltJjpaGQ9HPLB5szWcVuyiq6kKcO8tEXHd5sLOWpG6+3DppswOUdGd nNhN81TLlnMGVB6R3JA9oOTYhNDq86AxxJBQbmfpo3J4rpgDPz6xWvbbfJkEsVdVqc mdehCDDjbWHCRXCkStYWtzB8m2J+w31zTkCl+5KsoLnC1y15sGk+SXNSBQTMosJai+ B1eNZ1TvxyXOGJ7xk6BLr6NpaYgurkNwHQyLDz8amMHgEs3s+6tfcraRfBQBNEJSR5 YJ2Bs3nlzGlZunSIGgRC6wKcSfTmpeVmvO2Qc4AGFkNh4k2GaGF7p07rkqt70V5bVw 3aeUOIu9r/5aw== Date: Wed, 12 Aug 2026 11:53:29 +0100 From: "Lorenzo Stoakes (ARM)" To: Xie Yuanbin 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 Message-ID: References: <20260812091644.224299-1-xieyuanbin1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > --- > 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