From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1969BC28B28 for ; Wed, 12 Mar 2025 08:18:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FA84280002; Wed, 12 Mar 2025 04:18:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A9CA280001; Wed, 12 Mar 2025 04:18:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79964280002; Wed, 12 Mar 2025 04:18:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5CA72280001 for ; Wed, 12 Mar 2025 04:18:44 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DC0F4120CE6 for ; Wed, 12 Mar 2025 08:18:44 +0000 (UTC) X-FDA: 83212197768.18.6F00E3E Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf30.hostedemail.com (Postfix) with ESMTP id 588F980008 for ; Wed, 12 Mar 2025 08:18:42 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of rakie.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=rakie.kim@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741767523; a=rsa-sha256; cv=none; b=A4W4k5Kp52BMCtPJpC6091jbgTw2tj2JeuOwYTobuSMtWDsxiFsilW5KRUhkhYmAed3z9G srhc6WVpUh2bZsmWLGbnIqIoXk8BE0pWhVm7bV2OIVZPKo1QfwuqzWSr8DGM1/DOMAEptP 8cME+pqA94rXRGIhugQYau2Z5pUN7a0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of rakie.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=rakie.kim@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741767523; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wdv15wcC/qgWgcHp79mDHaZWCa6rRWsIjXCjxwuFsik=; b=MP4Jyw1HG2pRKFtlspHJrHlFRh4PdcsA177hu0+TaUSQiAI+2EysnXeHt9ejsvdlHED9Rf sNW/QM/aBU6j9sgcvG0obuIchnGOM+w8+wjzDdU7LDA2oTIMPRPoImlTv0q39CyhSh7eHw +6/h46F+O83n7svHSKY5Ck/UFNAkU6c= X-AuditID: a67dfc5b-681ff7000002311f-9d-67d14360e15c From: Rakie Kim To: Gregory Price Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, joshua.hahnjy@gmail.com, dan.j.williams@intel.com, ying.huang@linux.alibaba.com, kernel_team@skhynix.com, honggyu.kim@sk.com, yunjeong.mun@sk.com, Rakie Kim Subject: Re: [PATCH 0/4] mm/mempolicy: Add memory hotplug support in weighted interleave Date: Wed, 12 Mar 2025 17:18:21 +0900 Message-ID: <20250312081836.665-1-rakie.kim@sk.com> X-Mailer: git-send-email 2.48.1.windows.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsXC9ZZnkW6C88V0gz9LLC3mrF/DZjF96gVG i593j7NbHN86j93i/KxTLBaXd81hs7i35j+rxeo1GQ4cHjtn3WX36G67zO6xeM9LJo9Nnyax e5yY8ZvFY+dDS4/Pm+QC2KO4bFJSczLLUov07RK4Mm5fPMBS8FOkYtqxe0wNjKcEuhg5OCQE TCTaZhV3MXKCmbeuvmYHCbMJKEkc2xsDYooIqEq0XXHvYuTiYBZYzyTxetMsNpByYYEIiadn WlhBbBagmts/HzOD2LwCxhK9p+awQYzUlGi4dI8JxOYUMJN403uEHcQWEuCReLVhPyNEvaDE yZlPWEBsZgF5ieats5lBlkkInGGTmLNzJtQgSYmDK26wTGDkn4WkZxaSngWMTKsYhTLzynIT M3NM9DIq8zIr9JLzczcxAoN4We2f6B2Mny4EH2IU4GBU4uEVyLmQLsSaWFZcmXuIUYKDWUmE d7UtUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv0bfyFCGB9MSS1OzU1ILUIpgsEwenVAOj7gNG /43qzp7B7xfZVzjVMjyImCBz/OI5pXd6JfFfVxxRzWXl+/WEz21RwFwJ9fqZGkJZj07fOXP0 DovJ0cd3V9adWiWwxVbogFbgEYVZqsKvL58+3vnmnmeBUXF/UeJa/8uve9XUu+ovCazq5Ci8 VSCy7pB1nWPM6ZXb13VMu1a39sSexov8SizFGYmGWsxFxYkAX0UZtl4CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsXCNUNNSzfB+WK6wfwnRhZz1q9hs5g+9QKj xc+7x9ktPj97zWxxfOs8dovDc0+yWpyfdYrF4vKuOWwW99b8Z7U4dO05q8XqNRkWv7etYHPg 8dg56y67R3fbZXaPxXteMnls+jSJ3ePEjN8sHjsfWnp8u+3hsfjFByaPz5vkAjijuGxSUnMy y1KL9O0SuDJuXzzAUvBTpGLasXtMDYynBLoYOTkkBEwkbl19zd7FyMHBJqAkcWxvDIgpIqAq 0XbFvYuRi4NZYD2TxOtNs9hAyoUFIiSenmlhBbFZgGpu/3zMDGLzChhL9J6awwYxUlOi4dI9 JhCbU8BM4k3vEXYQW0iAR+LVhv2MEPWCEidnPmEBsZkF5CWat85mnsDIMwtJahaS1AJGplWM Ipl5ZbmJmTmmesXZGZV5mRV6yfm5mxiBobus9s/EHYxfLrsfYhTgYFTi4T2geiFdiDWxrLgy 9xCjBAezkgjvalugEG9KYmVValF+fFFpTmrxIUZpDhYlcV6v8NQEIYH0xJLU7NTUgtQimCwT B6dUA+PJ6BxDRcXPHTP2REzS/fZGwSGNZUJPJIeQ1zGHXW3JNYnPbhv3bCusWjfNwKGr++Zc 09MvJ18oatkcFtHbtrr96NRvka9jj36Ys1xH6dtnLfF3CXf0Qlt9Xr9MFr+iJ+a1tnnPv3O5 +62Ms5MatH733exN+fd4X47z4+qL//aemTDXkfFPRasSS3FGoqEWc1FxIgDli6M4WQIAAA== X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 588F980008 X-Stat-Signature: 5ag1r4j84hhg311o15ym3zr87nog5t47 X-Rspamd-Server: rspam06 X-HE-Tag: 1741767522-763816 X-HE-Meta: U2FsdGVkX1983acynoUYGePdhvtT4JQ16xNoAt7f1ib00rrFbywS1MTSuINbLOHZZ3nHrdzdcF3KICMbnKeFPcCUQrjBCMxCNnTRYM72Evq8tUIj+p63Vvg7ctLvht80WGW67XEhsxcHRo3ZtzDek2mDQ6ASMTBQdv8ZyLevE8eZDgF777HL5SUTJsnFER7XXLWiLAk97WkMf8bV0eqykpxdNgfSRaAVnhqziNuaM10Wd/YAMf980g2gKhaKasi7+F3qeKiyaEIVToys/+7FhCO2U0j2HgeznU4TSYx7gbJ9je9Ls/OiVT0NRFHdRYrsP63LlOKcJQ/jcVLNLY7aVkoElQ7w63UMyJRdB44w6xaEEm5EF8/KRqUGbKpZxtn7rKYYTjyu0VpwlTmH0UXUAcpJL8OUl1s4uPqj2N7IhHUXvD6Jy8YeWLbhjwLTKTc03QwP17+AlPtdedlQGHL4n7NchLC1fPTc06ZykU+SJyGoZhupnmbxCqCn4LjRo3pvnALz5Hve8L4KJUyCD8ouPEHAmyEUpSjEp8+/Z9dYBaPwwjt+RDm/nN/wW2tjIRExLtDVddeVbip4GHrTCBOCooS4DfGEpvHoMaRhlhQcRyLvukxb8Aayqxe9lnOp+kjca0ljgnE4ILlaY06ihuov6Aei3r9LWbXj4ChB35RG5IY3ztLIOVmeg5Kp81fmaPrJC/F7I74Fv3J4Ota+tMDtZ28WuUyp/0a7u858hoMvEOla7W07y2UP3UvJnJlyiDbVX2SviW5GCz/rBktJkHZr/bCOe3Eg7aTuSun8iagPxZSt2CG9VFV0IbCSoa5QTVMo6tRVE3BoXmDsy0MjedpO3SWOL1fOj6G3V6EMdcHIzgYrOerSWxHW5iEG9PEkgExzoWk6GL9sd/QmM6dT3Hi0w1L/aNYoR16lhabpYZrxfizLXssR6bzm4AbTyAXL41ERTR1lcxVSzxpVIE1E2tL E3v8E2Ji WGwyxcRWxBfriMjI9JgoT4y24+MfrzhEzY5Tv4Np1DS97NS6XcazoSdoHyt5pP49V2iuQAHHrKeHxYoYyZ6VwNex7SIWqRENIH1O6KFOsj7DYmCmqkAgSqQjemAa9rMYTvxhD X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, 10 Mar 2025 10:13:58 -0400 Gregory Price wrote: Hi Gregory, I have updated version 2 of the patch series, incorporating the feedback from you and Joshua. However, this version does not yet include updates to the commit messages regarding the points you previously mentioned. Your detailed explanations have been incredibly valuable in helping us analyze the system, and I sincerely appreciate your insights. > 2) We need to clearly define what the weight of a node will be when > in manual mode and a node goes (memory -> no memory -> memory) Additionally, I will soon provide an updated document addressing this and other points you raised in your emails. Thank you again for your guidance and support. Rakie > On Mon, Mar 10, 2025 at 06:03:59PM +0900, Rakie Kim wrote: > > On Fri, 7 Mar 2025 16:55:40 -0500 Gregory Price wrote: > > > On Fri, Mar 07, 2025 at 10:56:04AM -0500, Gregory Price wrote: > > > > > > > > I think the underlying issue you're dealing with is that the system is > > > > creating more nodes for you than it should. > > > > > > > > > > Looking into this for other reasons, I think you are right that multiple > > > numa nodes can exist that cover the same memory - just different > > > regions. > > > > > > > I understand your concerns, and I agree that the most critical issue at the > > moment is that the system is generating more nodes than necessary. > > We need to conduct a more thorough analysis of this problem, but a detailed > > investigation will require a significant amount of time. In this context, > > these patches might offer a quick solution to address the issue. > > > > I dug into the expected CEDT / CFMWS behaviors and had some discussions > with Dan and Jonathan - assuming your CEDT has multiple CFMWS to cover > the same set of devices, this is the expected behavior. > > https://lore.kernel.org/linux-mm/Z226PG9t-Ih7fJDL@gourry-fedora-PF4VCD3F/T/#m2780e47df7f0962a79182502afc99843bb046205 > > Basically your BIOS is likely creating one per device and likely one > per host bridge (to allow intra-host-bridge interleave). > > This puts us in an awkward state, and I need some time to consider > whether we should expose N_POSSIBLE nodes or N_MEMORY nodes. > > Probably it makes sense to expose N_MEMORY nodes and allow for hidden > state, as the annoying corner condition of a DCD coming and going > most likely means a user wouldn't be using weighted interleave anyway. > > So if you can confirm what you CEDT says compared to the notes above, I > think we can move forward with this. > > ~Gregory