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 3EA9337188B for ; Thu, 13 Aug 2026 09:31:37 +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=1786613499; cv=none; b=A09Hc5sUxvKfjLgYmAbXUqUKLVvWfLa6/eMM1FVUTJ1LnnT89iBorkvz6Ytx7t0QQdcsixn8u2fKChMWl6NglSF3JJ17JGOETfrQNf8K84VjBXo7iUATMnLY4e2if11gixlbtveboRXcjGWhCVuU4ZaqhU/szv7li6lOx36DL10= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786613499; c=relaxed/simple; bh=2yLspY1Jo93SiQQHjmg1ogZvvxCwA5uk3pjnFOj6A+A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rJMN0p/I1uN2zOhgXKf563MmVnJYhyHjowGARXNND8s98vlNZ3v6MFIWhuK1w7e4F0cfzYdQBGDT9lFtVhGCAhpOOABrxcFNGCeA4iptOPDEOVR1YyQ8wPoHsCELEiaLG4WdaPoYlzDtLPt8++MlwvjaiG+q2TSsRXZi4g2G1eA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mt1DAUli; 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="Mt1DAUli" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 264371F000E9; Thu, 13 Aug 2026 09:31:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786613497; bh=RPWRbYV6TCDAvxwAQ93r3v8jMQsGV73j+wzwL5QA0LI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Mt1DAUli6E0KbctTMEUJSRtrDQt3jR7WNsGXypzFOmMb4zRkFkZrMgW/HP9bC8TWV 864GweWLaUewxzREk5i/Trv07mMBnEdtKN0EOaPz7pjLJNujHFJZVnQ3H0e4JqPVKt jsWrbVwp+kL5kr+aY2a/eP4VoFqtxJBV2EG6Npi5V+iJLJC6b7Y+zxiZDecN1VHBu7 Oiskh1H9493M1rkzR95i/8kYUaMsjtMZmvUrbAi18rJ5niihmnRwF7/ROMTM47lj7H Ff3mCt3CBqo7Z8WeQdP9QUhF80uN53Vl1lKZa764tP53Bs6/UCXch97fy800Uvef4j whKleZqLtk+2g== Date: Thu, 13 Aug 2026 10:31:15 +0100 From: "Lorenzo Stoakes (ARM)" To: Xie Yuanbin 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 Message-ID: References: <20260812115529.247548-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: <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