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 99A88C61CE8 for ; Mon, 9 Jun 2025 12:31:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9D2E6B0089; Mon, 9 Jun 2025 08:30:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D26386B008C; Mon, 9 Jun 2025 08:30:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C15A26B0092; Mon, 9 Jun 2025 08:30:59 -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 A45E26B0089 for ; Mon, 9 Jun 2025 08:30:59 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 204A1C08AD for ; Mon, 9 Jun 2025 12:30:59 +0000 (UTC) X-FDA: 83535796638.04.E31ED52 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf15.hostedemail.com (Postfix) with ESMTP id 6AFCAA0013 for ; Mon, 9 Jun 2025 12:30:56 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749472257; 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=Y+3zRNKoaxmLNEpdfqtq2YeEdmbcp08QAq7mR0iAuGU=; b=5jqLdyK/NnOiM/YY4HZK3Pp7D4vaO6UDv/+giH+bgWzZEGP8zHYqNy/ZpVGgIduPj7kf/h 2ioE8jM1+IHDTNBB7lV9R7y3h5hrdpCuh1BjKC34aBTFexFYumC12TRDY44goSYEP8QJ6D Tzi9mOIfJVXS4KDkN51q6AqO8dHLfrY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749472257; a=rsa-sha256; cv=none; b=IPncc0LkLPRYRDK7oZJURLDgGW9hPOf3dlYpF2ZNfsBJ06yRWgpI7xz2x+DwOUsDpqe9P2 aJv6FnLOzQAF+HQRFMcmfHPHD9NS52HX+SxbQmN6fV311r9+Irao91LTpbbvmJ73PS9PqW Pq1MmkzK6QlK5b+4gVa6Jsis+iK/XDs= X-AuditID: a67dfc5b-669ff7000002311f-b4-6846d3fd693d Message-ID: <74a7db85-8fcc-4bd5-8656-0f4d0670f205@sk.com> Date: Mon, 9 Jun 2025 21:30:53 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: kernel_team@skhynix.com, david@redhat.com, mhocko@kernel.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, damon@lists.linux.dev Subject: Re: [PATCH 2/2] mm/damon/sysfs-schemes: add use_nodes_of_tier on sysfs-schemes Content-Language: ko To: wangchuanguo , akpm@linux-foundation.org, hannes@cmpxchg.org, sj@kernel.org References: <20250528111038.18378-1-wangchuanguo@inspur.com> <20250528111038.18378-3-wangchuanguo@inspur.com> From: Honggyu Kim In-Reply-To: <20250528111038.18378-3-wangchuanguo@inspur.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsXC9ZZnke7fy24ZBqs3WFvMWb+GzeLJ/9+s Fl/X/2K2WL3J1+LyrjlsFvfW/Ge1ODlrJYvF62/LmC2ez5rLZHH46xsmi+OfnzNbfLpygN2B x+PfiTVsHoffvGf2OLFjA7PHplWdbB6bPk1i9zgx4zeLx8KGqcweLzbPZPT4+PQWi8f7fVfZ PD5vkgvgjuKySUnNySxLLdK3S+DK+DltLWPBLbGKR8c0GxjvCXQxcnJICJhIrPjxhR3GfvP5 NhOIzStgKfHt+T5GEJtFQEXiwY07bBBxQYmTM5+wgNiiAvIS92/NAOrl4mAWuM8osXxyN1hC WCBSYsWtfrAGZgERidmdbcwgtohAlsT7/VvBhgoJ5Es8ajsOFmcTUJO48nIS0GIODk4BW4kt v6FazSS6tnYxQtjyEtvfzmEG2SUh0M4u8ejeNTaIoyUlDq64wTKBUXAWkvtmIVk9C8msWUhm LWBkWcUolJlXlpuYmWOil1GZl1mhl5yfu4kRGHnLav9E72D8dCH4EKMAB6MSD+8JYEQKsSaW FVfmHmKU4GBWEuFdCRLiTUmsrEotyo8vKs1JLT7EKM3BoiTOa/StPEVIID2xJDU7NbUgtQgm y8TBKdXAuHrKkWealWs9TR1DZzvHszi8v5Su1H2I5ekqu6nFzHcu7WBYUsp2qrIrfvaJcv/o hut9hpteNr0Ofr4vzMjlea9sooUBu+yhQ1Zxqa9un6gISgu7daRwZ2H5vb4VsxJMBVZMi0y+ 7NegqnDhibrqFZO2K/OTvRbf+9Z+3d/q2FZRwe8Va7XOKrEUZyQaajEXFScCAEnz0yy4AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42LhmqGlp/v3sluGwfdFOhZz1q9hs3jy/zer xdf1v5gtVm/ytTg89ySrxeVdc9gs7q35z2pxctZKFovX35YxWzyfNZfJ4vDXN0wWxz8/Z7b4 dOUAuwOvx78Ta9g8Dr95z+xxYscGZo9NqzrZPDZ9msTucWLGbxaPhQ1TmT1ebJ7J6PHx6S0W j/f7rrJ5LH7xgcnj8ya5AJ4oLpuU1JzMstQifbsEroyf09YyFtwSq3h0TLOB8Z5AFyMnh4SA icSbz7eZQGxeAUuJb8/3MYLYLAIqEg9u3GGDiAtKnJz5hAXEFhWQl7h/awZ7FyMXB7PAfUaJ 5ZO7wRLCApESK271gzUwC4hIzO5sYwaxRQSyJN7v3wo2VEggX+JR23GwOJuAmsSVl5OAFnNw cArYSmz5DdVqJtG1tYsRwpaX2P52DvMERr5ZSM6YhWTDLCQts5C0LGBkWcUokplXlpuYmWOq V5ydUZmXWaGXnJ+7iREYR8tq/0zcwfjlsvshRgEORiUe3hPA+BJiTSwrrsw9xCjBwawkwrsS JMSbklhZlVqUH19UmpNafIhRmoNFSZzXKzw1QUggPbEkNTs1tSC1CCbLxMEp1cB4RmOJ9Haf v4oz1OZ+1eIT5io+qnT5QGHkY0dWLufvBUotdhedymfOzEnpDD1ivyxzdfr6BW2PQq/8WrVr 7q1rF39cuyQl6sPfd46nqUSn+rHY2tc5pz/PW3mkelKtYq5tXkhG2aTyn8IJpeeXZ4U7LFbL 2Xz1rWe4aeRuvhfz5RuaHsdZ9yUosRRnJBpqMRcVJwIA8WlOj58CAAA= X-CFilter-Loop: Reflected X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6AFCAA0013 X-Stat-Signature: 6gbcqyc38mu4yayqceys9xmh8d6g7bee X-Rspam-User: X-HE-Tag: 1749472256-130046 X-HE-Meta: U2FsdGVkX1+ZRATMkfmx3D0GV4pED/D8D2QePQMAWko5kTe/QJ2J1Y6Jhik178DGrUH7kYww0xKYHsjlDb6mycAuPcvoQKW+0NPyJflOG89lxjpOsw2WXBnqR9JvyHDhrBFMMt/srpi6bvOrJPVoNT3hdb07u9iNWmRX1L/ZNbN7QEU/tqzrO31BlK/brXUK1+ARandTtSLCHR4gRiNkFYbpGF+Iz0r0caUK60PLo9acKNPHzYoGGkGj2PMBXvTCg6pgF0Fq+mAnk6JtTgyTjZVp0nCsYh10Q5+XwNbq26kJf9/3ipS4evXHB70uIiSu2FMKKO/T7Qw2HJWBRZ19UN2YIuBcR7MoaEXEBWtg37fZ2qW/KTAChRUTQsk+RBmdNHBDYCQmwIKmim2YTjKUpqDbCJJEuXfWaq6IphCSu8xoubW7UkMDZtH1tDsuUNqjKwDnm5r9sdvDBXQU8siU96HfWUIdaAZOMHEoAK+S+FTH+ySKdv40cmjcqbhYB2R2KIaMsg6LSB7oBNOKq/wx9baNS+wuadqM5vYzFaP0hJOwQ7Um+VMFfGz75COGar7zcpDyI6rLWtaJC38gWkibg0iIKWe/z5PueTcWbKqRFAll58E5qgNa2suol901vXirfUNMu6yH7rIBGE1VtQRrSAQG+IlE4NHn8lLhVOr8FmSb32BzyBQRRT3bns+K9qUA+X2l7Uyyj5YFZX+uEyoV3WIzyosTgzcqBGP6cS9Urqft7BOObR03Ulb5dUbSAKf0MG0qtVtmGgMcFm/HRFpKjHD7VQgZvWfU3lsNuqpZzFg= 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 Simon and SeongJae, Sorry for the late response. On 5/28/2025 8:10 PM, wangchuanguo wrote: > This patch adds use_nodes_of_tier under > /sys/kernel/mm/damon/admin/kdamonds//contexts//schemes// > > The 'use_nodes_of_tier' can be used to select nodes within the same memory > tier of target_nid for DAMOS actions such as DAMOS_MIGRATE_{HOT,COLD}. > > Signed-off-by: wangchuanguo > --- > include/linux/damon.h | 9 ++++++++- > include/linux/memory-tiers.h | 5 +++++ > mm/damon/core.c | 6 ++++-- > mm/damon/lru_sort.c | 3 ++- > mm/damon/paddr.c | 19 ++++++++++++------- > mm/damon/reclaim.c | 3 ++- > mm/damon/sysfs-schemes.c | 31 ++++++++++++++++++++++++++++++- > mm/memory-tiers.c | 13 +++++++++++++ > samples/damon/mtier.c | 3 ++- > samples/damon/prcl.c | 3 ++- > 10 files changed, 80 insertions(+), 15 deletions(-) [...snip...] > diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c > index e8464f7e0014..e13321cff38f 100644 > --- a/mm/damon/paddr.c > +++ b/mm/damon/paddr.c > @@ -383,7 +383,7 @@ static unsigned long damon_pa_deactivate_pages(struct damon_region *r, > > static unsigned int __damon_pa_migrate_folio_list( > struct list_head *migrate_folios, struct pglist_data *pgdat, > - int target_nid) > + int target_nid, bool use_nodes_of_tier) > { > unsigned int nr_succeeded = 0; > nodemask_t allowed_mask = NODE_MASK_NONE; > @@ -405,6 +405,9 @@ static unsigned int __damon_pa_migrate_folio_list( > if (list_empty(migrate_folios)) > return 0; > > + if (use_nodes_of_tier) > + allowed_mask = get_tier_nodemask(target_nid); I have a concern about this part. This might work but, IMHO, the current memory tier doesn't provide a concept of cross socket bridge, which is UPI in Intel. For example, please see the following topology. node0 node1 +-------+ UPI +-------+ | CPU 0 |-------| CPU 1 | +-------+ +-------+ | DRAM0 | | DRAM1 | <-- memory tier 0 +---+---+ +---+---+ | | +---+---+ +---+---+ | CXL 0 | | CXL 1 | <-- memory tier 1 +---+---+ +---+---+ node2 node3 Even if some nodes are in the same memory tier, but if those are in the different socket side, then the migratio makes the situation worse unexpectedly. For example, if the page at node0 is tried to be demoted to node2, but if node2 is full then the current behavior is to cancel the demotion, but this change makes it to be demoted to node3, which is on the other side of socket. Since the cross socket access is a lot worse, I worry about this change. Please let me know if you have a different thought. Thanks, Honggyu