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 4C6ECC021B8 for ; Tue, 4 Mar 2025 13:03:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4E316B007B; Tue, 4 Mar 2025 08:03:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CFE936B0082; Tue, 4 Mar 2025 08:03:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC6AC6B0085; Tue, 4 Mar 2025 08:03:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9D86E6B007B for ; Tue, 4 Mar 2025 08:03:28 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5D3BDB7DE7 for ; Tue, 4 Mar 2025 13:03:28 +0000 (UTC) X-FDA: 83183884896.19.B290020 Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf17.hostedemail.com (Postfix) with ESMTP id A43FB40015 for ; Tue, 4 Mar 2025 13:03:24 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf17.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741093406; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/7BilD8dORpxrzZvN6HyFPQzh0Gv7CdY/wPFd+pjT2M=; b=mXttpL0qmFx48cao/WEI4avQwFcXil3mqv9gg8Kxre9zc6e4rgZR0jJiy4lXKp1HF5yH1+ dlNoVYQxyIIjafja6fJ0YV6NGO/jQfYRaBh3kDTLhsSd2X1IZzL32diqZUB1RsotG2YwOr Py2wRuierSGkpRQkF5jDPTC0KaOKfr8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741093406; a=rsa-sha256; cv=none; b=0DBpV6H0S4aOFm/gQTGGpHL0AMCv9jv3jhQzppqvky0Uy5IeOlBhA6ECeMjuXoPUjbekW7 CQoh3MOLiI8HRLnnsiNwqQLYYGX9ApZcweI8s1BPLf078qqbA/oo1EL0e7P2fr2mu7E8rf ii32Fr5IXjpW1vdeVYM6Madmo7Pst0M= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf17.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com X-AuditID: a67dfc5b-3e1ff7000001d7ae-c9-67c6fa1bc9a6 Message-ID: <95541985-8d40-4ded-a83e-46203c441640@sk.com> Date: Tue, 4 Mar 2025 22:03:22 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: kernel_team@skhynix.com, Joshua Hahn , harry.yoo@oracle.com, ying.huang@linux.alibaba.com, gregkh@linuxfoundation.org, rakie.kim@sk.com, akpm@linux-foundation.org, rafael@kernel.org, lenb@kernel.org, dan.j.williams@intel.com, Jonathan.Cameron@huawei.com, dave.jiang@intel.com, horen.chuang@linux.dev, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com, yunjeong.mun@sk.com Subject: Re: [PATCH 2/2 v6] mm/mempolicy: Don't create weight sysfs for memoryless nodes Content-Language: ko To: Gregory Price References: <20250226213518.767670-1-joshua.hahnjy@gmail.com> <20250226213518.767670-2-joshua.hahnjy@gmail.com> From: Honggyu Kim In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsXC9ZZnka70r2PpBvP+81jMWb+GzWL61AuM FiduNrJZ/Lx7nN2iefF6NovVm3wt7i97xmJxu/8cq8WqhdfYLI5vncduse8iUMPOh2/ZLJbv 62e0uLxrDpvFvTX/WS3mfpnKbLF6TYaDoMfhN++ZPXbOusvu0d12md2j5chbVo/Fe14yeWxa 1cnmsenTJHaPEzN+s3jsfGjpsbBhKrPH/rlr2D3OXazw+Pj0FovH501yAXxRXDYpqTmZZalF +nYJXBk7V31gLtjMXzH74EWmBsZOni5GDg4JAROJFS1MXYycEOa+fywgYV4BS4mzl4NAwiwC KhKL7raygNi8AoISJ2c+AbNFBeQl7t+awd7FyMXBLPCYWeLTnS5mkISwQJTEzld/wWYyC4hI zO5sYwaZKSKgKtF2xR2kXkjgLKPE23f7GUFq2ATUJK68nARWzylgJjF93112iF4zia6tXYwQ trzE9rdzmEGaJQTusUtM33OUDeJoSYmDK26wTGAUnIXkwFlIds9CMmsWklkLGFlWMQpl5pXl JmbmmOhlVOZlVugl5+duYgTG8LLaP9E7GD9dCD7EKMDBqMTDG/DzWLoQa2JZcWXuIUYJDmYl EV7Tz0Ah3pTEyqrUovz4otKc1OJDjNIcLErivEbfylOEBNITS1KzU1MLUotgskwcnFINjJMZ P27X9TPoK6+X/Pf/+uJX/S09Wz9pZugKaWd594W1TGy996ik6OcDxi55K5knM/M496neKFty MlSaXd1+mczuiTK6h5f1s1dxLv9w48nTcpc1qbdfXo7jmftuV+Y9X5m94SrKqg+UJbmvv6hs 2jplZ77Z4Uy9N81Ktg85+LTm1dlejSqSVmIpzkg01GIuKk4EADZxK+HdAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsXCNUNLT1f617F0g5NrmC3mrF/DZjF96gVG ixM3G9ksft49zm7RvHg9m8XqTb4W95c9Y7G43X+O1WLVwmtsFse3zmO32HcRqOHw3JOsFjsf vmWzWL6vn9Hi8q45bBb31vxntZj7ZSqzxaFrz1ktVq/JsPi9bQWbg4jH4TfvmT12zrrL7tHd dpndo+XIW1aPxXteMnlsWtXJ5rHp0yR2jxMzfrN47Hxo6bGwYSqzx/65a9g9zl2s8Pj49BaL x7fbHh6LX3xg8vi8SS5AIIrLJiU1J7MstUjfLoErY+eqD8wFm/krZh+8yNTA2MnTxcjJISFg IrFi3z+WLkYODl4BS4mzl4NAwiwCKhKL7raygNi8AoISJ2c+AbNFBeQl7t+awd7FyMXBLPCY WeLTnS5mkISwQJTEzld/mUBsZgERidmdbcwgM0UEVCXarriD1AsJnGWUePtuPyNIDZuAmsSV l5PA6jkFzCSm77vLDtFrJtG1tYsRwpaX2P52DvMERr5ZSO6YhWTFLCQts5C0LGBkWcUokplX lpuYmWOqV5ydUZmXWaGXnJ+7iREYr8tq/0zcwfjlsvshRgEORiUe3oCfx9KFWBPLiitzDzFK cDArifCafgYK8aYkVlalFuXHF5XmpBYfYpTmYFES5/UKT00QEkhPLEnNTk0tSC2CyTJxcEo1 MHod1NCetdD1nQDDxL85Grl7EgxOVm7wfN2lz7Xy9I513jbbpidXzxW7lnl+4dPNJSctTp8O augW9zK3maCc9Zc/3jrm571zW/U2/Tfe2dGbJrYsfl9AyaVLe+vC7ZXtDm6z1lwwa4rehSsr +Ms7izefy9gsNvW9c8hDq1PnrfMXpmwx77i4+K8SS3FGoqEWc1FxIgD06bnY0wIAAA== X-CFilter-Loop: Reflected X-Stat-Signature: tsewkos7n378r5a1o11jizpmo6c7m7na X-Rspamd-Queue-Id: A43FB40015 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1741093404-66634 X-HE-Meta: U2FsdGVkX1871j/1Z8fgNf4ZAclQ6JHyjtBtLUSE40CrwXv/1ojnfLOngiivmFNA4purGm/GTcnsHbEXCbcLNlNdgwKsclKS74xzh5Nu5OnIyVpg4CJMKyYR7AaWH1F/OwIWQQdici2uovowL3zNNIUOX/sEk4gWpt+RUNwZA5W2wsiIY41384v7Vzqw0tCotBWjZcs5MN+ayTBq6pjVe9UyM0HIEqgD9UX69WlCVNiz82t94pfwY4DspQqiHpvWCsSDaWUxLfd63wZcP7q47NquNM7OXm+S1YABy8+bV1fbHDBJukPZghHFreIWtLJSUMnsS8lZkNw7URBhS0NGiVpRkH2ZTrZ7wS94LZg0dChKIbgisZWABebLV+QYUoFAkrYL72Fn648m9JKPhBx8Su5ZmCU8Jp6Asr3sD4QKbJ7zxdXN6nb6bCx2zlDgmVHXCAozBjagdAbzVZBHgD/M6C8m1QO8Ou87GTRT1zasjfhAPi+dfBSuETYyFf52P4Ic3LVSOiQjJQ3/kOXgUkhkMkkFlLEHx9wFaj13JO9bZcsJc5lHBcB/JxGTKzr+uG2IRV3VwANvE3aRmxz0A1mzuiOm0MwQV3/AfWsX0/OsFurNuPCqUMD4oObqZ39mXT2EoaNojcWQ9o7WHnITxaO+IwnX1TUErnyO2+SyOlEF9ZcBtZyGJMqnyllQbNOF8CQPE0JVspn0XCcMXMCP6KIiDcg7YndGS+94R8PGvq/rNZJXLPLQhf9njdHLepfzq5t8ijIPlVq4DckTOEvgP5qmlYN01oLJNPOHXa2EqsHgI7W2TZwlTyiIGD90t8VNZax5rjdJKt9KGwhniOsXni1TROPeb6Xjz2JtMEYYLkDUAPajvNcd79vaBeY3XeqBOKV/ZwnVQbuoWC0m+xJK9nQqErcZLplluA/tVJVNN/SjuJPRbA93jEVFcOrMgO7XJqcTAiyzWhNXYpYgXvHt0by Kc5OYxb5 pDncRKmwTgokZp0ivWPzaFcVTqXMwx26HmuHraLvqBmhYEjn0Bmh/Ai9j3L4YDQyynhXYl6COUQjBi9xHTaqBh+roow== 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: Hi Gregory, On 3/4/2025 1:19 AM, Gregory Price wrote: > On Thu, Feb 27, 2025 at 11:32:26AM +0900, Honggyu Kim wrote: >> >> But using N_MEMORY doesn't fix this problem and it hides the entire CXL >> memory nodes in our system because the CXL memory isn't detected at this >> point of creating node*. Maybe there is some difference when multiple >> CXL memory is detected as a single node. >> > > Hm, well, the node is "created" during early boot when ACPI tables are > read and the CFMW are discovered - but they aren't necessarily "online" > at the time they're created. > > There is no true concept of a "Hotplug NUMA Node" - as the node must be > created at boot time. (tl;dr: N_POSSIBLE will never change). > > This patch may have been a bit overzealous of us, I forgot to ask > whether N_MEMORY is set for nodes created but not onlined at boot. So > this is a good observation. I didn't want to make more noise but we found many issues again after getting a new machine and started using it with multiple CXL memory. > > It also doesn't help that this may introduce a subtle race condition. > > If a node exists (N_POSSIBLE) but hasn't been onlined (!N_MEMORY) and > bandwidth information is reported - then we store the bandwidth info > but don't include the node in the reduction. Then if the node comes > online later, we don't re-trigger reduction. > > Joshua we should just drop this patch for now and work with Honggyu and > friends separately on this issue. In the meantime we can stick with > N_POSSIBLE. > > There are more problems in this space - namely how to handle a system > whereby 8 CXL nodes are "possible" but the user only configures 2 (as > described by Hyonggye here). We will probably need to introduce > hotplug/node on/offline callbacks to re-configure weights. > > ~Gregory This work won't take a long time so I think we can submit a patch within a few days. Thanks, Honggyu