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 52827C3601A for ; Mon, 7 Apr 2025 09:38:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33F616B0008; Mon, 7 Apr 2025 05:38:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EEA56B000C; Mon, 7 Apr 2025 05:38:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B9686B000D; Mon, 7 Apr 2025 05:38:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 000FC6B0008 for ; Mon, 7 Apr 2025 05:38:29 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 310DA1603B4 for ; Mon, 7 Apr 2025 09:38:30 +0000 (UTC) X-FDA: 83306747580.01.8D576EB Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf03.hostedemail.com (Postfix) with ESMTP id 3133520006 for ; Mon, 7 Apr 2025 09:38:27 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.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=1744018708; a=rsa-sha256; cv=none; b=Fc6VZMyw5BRGEOYPORLOOpHrNAXcfhcTLAu3NlvneD3/JfZQ2cvYJ0IMLaxOc9ljUbLyV0 DxjYmgTIqbpDJtj+7D/Z0fKaAxMStmOqar37ps+M8T5qhBN95J4Nr9pMVz0Kf86CSfVvKx QPDB0eNsTGRSCmThQe1HX1dRUIrDKxQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.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=1744018708; 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=vs2NVxr8V23A8iVa6IuF2bhbJcelxZpmpbAy+Qz7qsg=; b=f/KWO8mt1QzvQif9k5IfSmnrPFnuHXcmJKE9a48GwuamJ5vrvpHgO2JFC2abxaI+aVGos8 LvuRqh0/un3i0U2ZGzx2/NIc5wgTBpdfeI2XStWH7wYTfyjFwibg+BfsPlAqUpCSJwJJgZ xuTbqFz/GCjfL9CwT7bKMpsv6Z0NSyw= X-AuditID: a67dfc5b-681ff7000002311f-82-67f39d12e7b3 From: Rakie Kim To: Dan Williams Cc: akpm@linux-foundation.org, gourry@gourry.net, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, joshua.hahnjy@gmail.com, ying.huang@linux.alibaba.com, david@redhat.com, osalvador@suse.de, kernel_team@skhynix.com, honggyu.kim@sk.com, yunjeong.mun@sk.com, Jonathan Cameron , Rakie Kim Subject: Re: [PATCH v6 2/3] mm/mempolicy: Prepare weighted interleave sysfs for memory hotplug Date: Mon, 7 Apr 2025 18:38:17 +0900 Message-ID: <20250407093822.428-1-rakie.kim@sk.com> X-Mailer: git-send-email 2.48.1.windows.1 In-Reply-To: <67f0157e498c9_464ec294df@dwillia2-xfh.jf.intel.com.notmuch> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsXC9ZZnoa7Q3M/pBkdmWFjMWb+GzWL61AuM Fl/X/2K2+Hn3OLvFqoXX2CyOb53HbnF+1ikWi8u75rBZ3Fvzn9XizLQii9VrMhy4PXbOusvu 0d12md2j5chbVo/Fe14yeWz6NInd48SM3yweOx9aerzfd5XNY/Ppao/Pm+QCuKK4bFJSczLL Uov07RK4Ms5/7mMrmCda8fP1EfYGxn8CXYycHBICJhLfmvcww9j3ju1m7WLk4GATUJI4tjcG JCwioC0xcc5BoBIuDmaBZmaJY78uM4IkhAXiJO6dXghmswioStzbepYdxOYVMJZ4suA4I8RM TYmGS/eYQGxOAU+J3ubdYLaQAI/Eqw37GSHqBSVOznzCAmIzC8hLNG+dDbZMQuA7m8SZl6eY IAZJShxccYNlAiP/LCQ9s5D0LGBkWsUolJlXlpuYmWOil1GZl1mhl5yfu4kRGAHLav9E72D8 dCH4EKMAB6MSD+8Ot8/pQqyJZcWVuYcYJTiYlUR4LU99ShfiTUmsrEotyo8vKs1JLT7EKM3B oiTOa/StPEVIID2xJDU7NbUgtQgmy8TBKdXAuMbZy6M8IG9XjJ3ETkuNiTPubZirK3s4Kzia deqqSz7Xaq2slhy1c5+6R+z8jBuHze5z6Lc9fn5N5l7spruZDBPudH1iNKy/JsmWPHeHyev2 hCsnPmzgeyLdYz8tiHN2iNm8BrOLQeJfbonHtz+eXBaRt2K6ROk8l8az5Qm3HTXbxLLd35i6 KbEUZyQaajEXFScCAEX99VB8AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsXCNUNNS1do7ud0g3PXdC3mrF/DZjF96gVG i6/rfzFb/Lx7nN3i87PXzBarFl5jszi+dR67xeG5J1ktzs86xWJxedccNot7a/6zWpyZVmRx 6NpzVovVazIsfm9bwebA77Fz1l12j+62y+weLUfesnos3vOSyWPTp0nsHidm/Gbx2PnQ0uP9 vqtsHt9ue3gsfvGByWPz6WqPz5vkAniiuGxSUnMyy1KL9O0SuDLOf+5jK5gnWvHz9RH2BsZ/ Al2MnBwSAiYS947tZu1i5OBgE1CSOLY3BiQsIqAtMXHOQeYuRi4OZoFmZoljvy4zgiSEBeIk 7p1eCGazCKhK3Nt6lh3E5hUwlniy4DgjxExNiYZL95hAbE4BT4ne5t1gtpAAj8SrDfsZIeoF JU7OfMICYjMLyEs0b53NPIGRZxaS1CwkqQWMTKsYRTLzynITM3NM9YqzMyrzMiv0kvNzNzEC g35Z7Z+JOxi/XHY/xCjAwajEw3uj8VO6EGtiWXFl7iFGCQ5mJRFey1NAId6UxMqq1KL8+KLS nNTiQ4zSHCxK4rxe4akJQgLpiSWp2ampBalFMFkmDk6pBsb9t/5lLrVYvrjq8en2V38lnvuX f+wwYUgIq3igq8A2Ldnade9TUWubAIVv9ulLHm/JPXLmibSczcFosd+vLr6bLGLsopok+1V4 S/EVrh0nbvhnnn76Mo3tZ5eeruyexnm7lUMnTRG6oZJ9tNvcKffFxD/W62ddvFfGe7yjQW7u non1yi+KgzWVWIozEg21mIuKEwHCdIh9dgIAAA== X-CFilter-Loop: Reflected X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3133520006 X-Stat-Signature: m7xetz5rkk3h656c8rxd86fgk1kjj7zc X-Rspam-User: X-HE-Tag: 1744018707-976934 X-HE-Meta: U2FsdGVkX18nRVv/0992cGSd9yktp+DPR2DIguUehA1UVDlmT8yRgJgtkyXY3zZhb629o2sUKZn8VgM8QfU/33oh0fSp2puA3YEnRpSya0tuzXlrtmCe4bma7eUB8AFCBUhQ6tscq+c9kOLQGWMkTrk9hEH3MEvVk/olx4IxFHdu9jqKa+slhasLgjEEjEMfbfofRGfI/UU5Y+hFD1+QbTYWZ74YVd6BfXDHqgKPKyiW8FstQUNcUoUjzxpk3DO/ZPOPW4PWzzEHRCNa8fFas+bkZphmdVJpJpW8MxeIgOC747NaCT6L414RRxPQAbBmbGLajx4AWcGLOKqLdvUcAFCxOFquznhJIyjYP0KkNzUJRxZLPJrBsrlVz2nEbuw6TX1fqKKgbIqea1r3hcp3DjgAH1SeF2DiWhKAVLkMSXVP3CaSP9Qo2YeO+rF8FaiGsEwIj3GO6Q2hmDB0rlb4FaMjJOdx257ivD2npHf99huy98nYtytiL9WGc/Jepe6sZTfHiyZh/ytZrBesh1YwDx4U2R+xDSHevTd8gVpm8+5e7NqiTyMWA1O1V0zXjFuDt6w0LD9lplenztsvD8EtrNf09NRzkR5BlUWeqNqgTBmxYaKx5vZMkwAPl/LwVYEFKtEUExZFJtBYKPONIEXchw6Jdlorh5ZwZd8Tp/f3J0Jgs/hGwjlG32/gq6R4rG8VlmVjBVr3Vtt7gdv/23pVgZqUzyV64Dm/l45k8BE3yd6iblOu0p2VcTiz1Aw2p3+XEzUWovLatYH1VhCLYMTlO4s+f8VMhNBwISuSLUV+h8Wj0WwtUH4hesaWvvR7H18w6q0QeOnHBUb0NTzZQxiJqNpV6mZ+2QaqVcL0B1cFN5WYUClRgPjWDfu9liLQTLlCyzdZ66aWiEi+kfCly8NM0o8+KgSok3tFSeyoSPLYKJRbxaFKPfyFGXSxUivnKPAqge15NNdtPYm53BG92FG Ow5pUOm2 ciNZUoFkiOCO3BPSAGzKiJlVWM3n9/ljx7Bm/0K75zjKuEzCqXh7z5wg3zp8OVUY8+x9cRS+QamiyKeQLIEOXtAGNIiC13tou3TcXihgzqyDYZKlE8DwMOIuErJkTUgf7ygWcX7gCnPzzjgM4j+jUBVn1GpUlzCqwtizU5UaoquFVVl3GFBB+hSHI7Q== 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, 4 Apr 2025 10:23:10 -0700 Dan Williams wrote: > Jonathan Cameron wrote: > > On Fri, 4 Apr 2025 16:46:20 +0900 > > Rakie Kim wrote: > > > > > Previously, the weighted interleave sysfs structure was statically > > > managed during initialization. This prevented new nodes from being > > > recognized when memory hotplug events occurred, limiting the ability > > > to update or extend sysfs entries dynamically at runtime. > > > > > > To address this, this patch refactors the sysfs infrastructure and > > > encapsulates it within a new structure, `sysfs_wi_group`, which holds > > > both the kobject and an array of node attribute pointers. > > > > > > By allocating this group structure globally, the per-node sysfs > > > attributes can be managed beyond initialization time, enabling > > > external modules to insert or remove node entries in response to > > > events such as memory hotplug or node online/offline transitions. > > > > > > Instead of allocating all per-node sysfs attributes at once, the > > > initialization path now uses the existing sysfs_wi_node_add() and > > > sysfs_wi_node_delete() helpers. This refactoring makes it possible > > > to modularly manage per-node sysfs entries and ensures the > > > infrastructure is ready for runtime extension. > > > > > > Signed-off-by: Rakie Kim > > > Signed-off-by: Honggyu Kim > > > Signed-off-by: Yunjeong Mun > > > Reviewed-by: Gregory Price > > Hi Rakie, > > > > Some things I was requesting in patch 1 are done here. > > Mostly I think what is wanted is moving some of that > > refactoring back to that patch rather than here. > > > > Some of the label and function naming needs another look. > > > > Jonathan > [..] > > > @@ -3430,27 +3437,24 @@ static ssize_t node_store(struct kobject *kobj, struct kobj_attribute *attr, > > > return count; > > > } > > > > > > -static struct iw_node_attr **node_attrs; > > > - > > > -static void sysfs_wi_node_release(struct iw_node_attr *node_attr, > > > - struct kobject *parent) > > > +static void sysfs_wi_node_delete(int nid) > > > > Maybe stick to release naming to match the sysfs_wi_release() > > below? I don't really care about this. > > I had asked for "delete" to pair with "add" and to not get confused with > a final kobject_put() callback. As Dan mentioned earlier, I also believe that "sysfs_wi_node_delete" is a more appropriate name than "sysfs_wi_node_release" because it pairs naturally with "sysfs_wi_node_add" and avoids confusion with a final kobject_put() callback. Rakie