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 A4197C282DE for ; Mon, 10 Mar 2025 09:03:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C08EB280002; Mon, 10 Mar 2025 05:03:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB83D280001; Mon, 10 Mar 2025 05:03:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8113280002; Mon, 10 Mar 2025 05:03:47 -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 8C4D5280001 for ; Mon, 10 Mar 2025 05:03:47 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F25471C9501 for ; Mon, 10 Mar 2025 09:03:48 +0000 (UTC) X-FDA: 83205053736.30.2F9C9F0 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf30.hostedemail.com (Postfix) with ESMTP id 76CBF80004 for ; Mon, 10 Mar 2025 09:03:46 +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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741597427; 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=R6BRix5UmHbRTJlxLpO/9/wMmlRGV5E2LiZYTW5Rnhc=; b=JlzXr3DCRvqe3dweM3tRdXat0LTy+OqwY2eDJgBKu18Eg/xcYTHpEBfAklkQ1dciJB3Xiw qHmRVuFua4VeEcoNUCcQt5puWmSAsD8s9cBZF64x+sdH0bWTh7lzhNvGQO59wQAn8YakBS qaqENHdQs486ZJzsW6uWIEea7KvRwL4= 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741597427; a=rsa-sha256; cv=none; b=o11ZbOon9jCmSTqhDxN1scbiuE3V4dKNfz2dWtfz2z+xNM5LSUsYBvchhU841Y6qUjEGig M9ePEzN6nx7/SoQsWmA6TbjPbviS8j7drDkM6qM5Nvgdb/3/uS4BqsjL5CIzrw0DFFT97K khsynAA/wu8U2YcvRqgC5jfe/e/XV4A= X-AuditID: a67dfc5b-3c9ff7000001d7ae-de-67ceaaf00db8 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: Mon, 10 Mar 2025 18:03:34 +0900 Message-ID: <20250310090340.620-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+NgFjrNLMWRmVeSWpSXmKPExsXC9ZZnoe7HVefSDfY9ZLSYs34Nm8X0qRcY LX7ePc5ucXzrPHaL87NOsVhc3jWHzeLemv+sFqvXZDhweOycdZfdo7vtMrvH4j0vmTw2fZrE 7nFixm8Wj50PLT0+b5ILYI/isklJzcksSy3St0vgyvixpI2poE284lzjUtYGxhVCXYycHBIC JhKPV81i6mLkALNXHTYCMdkElCSO7Y0BMUUEVCXarrh3MXJxMAusZ5J4vWkWG0insECExNMz LawgNgtQzeZtN8HivALGEpvfP2GCmK4p0XDpHpjNKWAm8XLDB3YQW0iAR+LVhv2MEPWCEidn PmEBsZkF5CWat85mBlkmIXCCTaJh2XJmiEGSEgdX3GCZwMg/C0nPLCQ9CxiZVjEKZeaV5SZm 5pjoZVTmZVboJefnbmIEBvGy2j/ROxg/XQg+xCjAwajEw/tg3tl0IdbEsuLK3EOMEhzMSiK8 attPpQvxpiRWVqUW5ccXleakFh9ilOZgURLnNfpWniIkkJ5YkpqdmlqQWgSTZeLglGpgTGdh uvtuUdnvTxIBjeeOe1/smO3G6X/r/ULtuj2SZU+NuAN/2nO3qvR8XrS2Ymm/x0zDNrEPhWn1 y+Yd5Ny98JLQtwNpZ72vH/36Xl+H+9p7lZbXcz8Z7X9bvbVcbNZWxhlaR54o6E2I/nRva6jv vAeRKnesLBoko31fpW16wvKIc+v1g3q7+5RYijMSDbWYi4oTAfMnmo1eAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsXCNUNNS/fDqnPpBsv+GVnMWb+GzWL61AuM Fj/vHme3+PzsNbPF8a3z2C0Ozz3JanF+1ikWi8u75rBZ3Fvzn9Xi0LXnrBar12RY/N62gs2B x2PnrLvsHt1tl9k9Fu95yeSx6dMkdo8TM36zeOx8aOnx7baHx+IXH5g8Pm+SC+CM4rJJSc3J LEst0rdL4Mr4saSNqaBNvOJc41LWBsYVQl2MHBwSAiYSqw4bgZhsAkoSx/bGgJgiAqoSbVfc uxi5OJgF1jNJvN40i62LkZNDWCBC4umZFlYQmwWoZvO2m2BxXgFjic3vnzCB2BICmhINl+6B 2ZwCZhIvN3xgB7GFBHgkXm3YzwhRLyhxcuYTFhCbWUBeonnrbOYJjDyzkKRmIUktYGRaxSiS mVeWm5iZY6pXnJ1RmZdZoZecn7uJERi4y2r/TNzB+OWy+yFGAQ5GJR7eB/POpguxJpYVV+Ye YpTgYFYS4VXbfipdiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9XeGqCkEB6YklqdmpqQWoRTJaJ g1OqgdHAS/xNycSb/QYL2AIfHdBzVdzH4/5gzfWqlMid/KZ7lkzg21Bz62LXJPkS2YAlgqFv bWpqN2WIh/e/KmdZkvQv6MLbTRIBvZteiM9xLpBd6sih/rnr1DfO3KD7DmL6GZsYl0z5cdao P+8af0Vs2wwxyTtphTka/KYv/iUFLLoj+DtVws3KXYmlOCPRUIu5qDgRAECD5n5YAgAA X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 76CBF80004 X-Rspamd-Server: rspam03 X-Stat-Signature: mx3xkq993xyn8pw8dhaqmmiysxf4ob4d X-HE-Tag: 1741597426-197168 X-HE-Meta: U2FsdGVkX19+n/vn86xg0MQ8hUHLsBQ8V0mme0jNwH1ef8F7FfZk/lLPBeyOuTErVI9ieUb9eZcMYrpcJ4JCsmhP/y6T/WqsaFh3xi5MDZySw+ggHPfs9hU/F3klNkqZC3EyJx1Mex3AZkDRCZZkZCjUnwsg1LuApohq/valZd/7hBt8eqf5hVmwaPGLwRjWdG2k9rbgcvmGH8xaUIwKI1pKpBQmKpwqbyW9WMvPffSttXUEMk2qAIhjV3DSk/4Ze059O3LNINQDy09Zxjn8eUyDqSxd3uh4gEESWqqk9m1Ru6usSnIjH9+h+j3swIj37s29KyJJfm65Cmg4NVPME6BZIPh22dusCBNrhF5AO4dhfLFGYYz2HH9eY6WAtgT/z+jUJshL3m4paS5fvYRFBa7BzFCWRenRBguQMLyGAeg1jK3HDN0x+y3nmCDvk7sHE1bPmyuCzLgPMtmuZpfXvDVU8ld/1zgsGlhaD85wxXWsFScdoXbhpNAut4i9cRpyZNQRAEfILvP6zRBISdnBGFxe1XyJ35xBSDraj0frsRvT1YpV8sBKPY9UpGwfUCYnmMXm7r2toV4TV/g9W1Sm11gtB7FqC+jmbkEU9O05Nqpk/GHqDQiMAppnJRKC0RtcMwu7AzhP3odZTs9MZg1HDY2FCs23DAQERDFoUXY9l3/BX0CLrzJDe9dQh3XKznpeqtCS2tbnEMg5WeQN1xWjOqj1L8ehapLf2WTMKDlNePlyEk37/h0AhZtIjXRGv+EITH4kHQlmsQPgYJmjNi2Z5EcLzTsC/Tqu5WUpJ4cJFISmFrYWTQxCteZG6tACGdQNHpyjL5RGJBQXpmUHTnupfWmWls7JmUHCyi+DhxBPjK1D+gJ3IPYmj/iDlwYPl510og5c2qE0NgWVQ0I52Be4l8FtBcWgfljpetMt+VpC3t2/ilSitnBBL+FVVt/ywy4K1G4eWiRBc8NuugSJLA4 I+lRjGhu CeQTFS6doasrhCuYvBnUk+zgZ81Ynz3eucZ4oTShc2yJ80omAqNP1Saby/H3LLzxYNsoog2GhhpLEv47qsgF4+OodueBxmkcDkfPT 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 Fri, 7 Mar 2025 10:56:04 -0500 Gregory Price wrote: Hi Gregory Thank you for your response regarding this patch. > On Fri, Mar 07, 2025 at 03:35:29PM +0900, Rakie Kim wrote: > > Unnecessary sysfs entries: Nodes without memory were included in sysfs > > at boot. > > Missing hotplug support: Nodes that became online after initialization > > were not recognized, causing incomplete interleave configurations. > > This comment is misleading. Nodes can "come online" but they are > absolutely detected during init - as nodes cannot be "hotplugged" > themselves. Resources can be added *to* nodes, but nodes themselves > cannot be added or removed. > > I think what you're trying to say here is: > > 1) The current system creates 1 entry per possible node (explicitly) > 2) Not all nodes may have memory at all times (memory can be hotplugged) > 3) It would be nice to let sysfs and weighted interleave omit memoryless > nodes until those nodes had memory hotplugged into them. > > > Dynamic sysfs updates for hotplugged nodes New memory nodes are > > recognized and integrated via the memory hotplug mechanism. > > Subsequent patches refine this functionality: > > > > Just going to reiterate that that there's no such this as a hotplug node > or "new nodes" - only nodes that have their attributes changed (i.e. > !N_MEMORY -> N_MEMORY). The node exists, it may just not have anything > associated with it. > > Maybe semantic nits, but it matters. The nodes are present and can be > operated on before memory comes online, and that has implications for > users. Depending on how that hardware comes online, it may or may not > report its performance data prior to memory hotplug. I agree with your assessment. The existing comments, as you pointed out, might indeed be confusing or misleading. I'll make sure this issue is addressed in version 2. > > If it doesn't report its performance data, then hiding the node before > it hotplugs memory means a user can't pre-configure the system for when > the memory is added (which could be used immediately). > > Hiding the node until hotplug also means we have hidden state. We need > to capture pre-hotplug reported performance data so that if it comes > online the auto-calculation of weights is correct. But if the user has > already switched from auto to manual mode, then a node suddenly > appearing will have an unknown state. > > This is why I initially chose to just expose N_POSSIBLE entries in > sysfs, because the transition state causes hidden information - and that > felt worse than extra entries. I suppose I should add some > documentation somewhere that discusses this issue. > > I think the underlying issue you're dealing with is that the system is > creating more nodes for you than it should. I will reply to your next comment on this issue soon. > > ~Gregory Rakie