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 906B6C5B543 for ; Fri, 30 May 2025 19:40:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E98FF6B01A1; Fri, 30 May 2025 15:40:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E49936B01A2; Fri, 30 May 2025 15:40:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D37E96B01A3; Fri, 30 May 2025 15:40:22 -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 B48BF6B01A1 for ; Fri, 30 May 2025 15:40:22 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4F72881422 for ; Fri, 30 May 2025 19:40:22 +0000 (UTC) X-FDA: 83500590684.23.FE0F443 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf17.hostedemail.com (Postfix) with ESMTP id 7FBEF4000F for ; Fri, 30 May 2025 19:40:20 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=o+AM3trI; spf=pass (imf17.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748634020; 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:dkim-signature; bh=eht3E2KS01ixJHxxelz8eRDzs+2gwiNLWXc3DAaynWU=; b=SU0qMPYMyHWRKkK+fq66XtqWYSgmotRmN04i6D5/s/AUkMtVt+hcxrloe1uK9HjUNZfg1Z 6NKQMRFyUDAZbqP0vfRkUwujf+qOUAbidPdnhJbXziBhXnajraMDSG4FNo4lXvDtBDLRhu adtvmoWYbzeKkewL+iI1bvmmRzo7F8I= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=o+AM3trI; spf=pass (imf17.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748634020; a=rsa-sha256; cv=none; b=TgVBJzEjVMbGWzk4XNgJwTlilKwRBqD1tONb1wktGd8LykKspLlEo04J+RWE9Lyi+JYhkD V6giJDjqVf+v7aHFQTgIBz8Ggyupoe6YWDyRwxcdvqu3MzwPEKCI0pK/JdTdfvMs5onr4P LDMgKfNw/eRM/h8v47hNeMAlsq2k7JU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id C84C4A4F9AC; Fri, 30 May 2025 19:40:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AF82C4CEE9; Fri, 30 May 2025 19:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748634019; bh=itUA8ff8aTmvXv85lYwlzfad/BJsQ7E+Twj2YKbMDQs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o+AM3trI1qH0ill10tQoKzosuizcbVRdiHm9o0M805oDppMqBYjOnkxWaefmSU5V4 XWJHP+fHXambmXZ9odTbZF+qQJU0SH3f+xNd3UKD+d+lwgVRpzY5BrJiEAt7jMu3l+ 1RdvpqOkhTp4pQh10pPbL6Fh8dxVuYa3/1tSVqX4nNiZrr/Bt134TTWnT9/Du6EiRF 2KWdzkQS1nFx6Hvc8pwCWrnk/Q6fdP64R/n7E/yXemb7jgyRt6H9rPIip1ZlHAHJXz 1p1etjkGIs2ue5mR13QVDRnzd7DMZPJzHYgokCudEfnuEtyFQaxjkDGv4Nc33NR2Br 80Lo6UYsQ6ytw== From: SeongJae Park To: Simon Wang Cc: SeongJae Park , "akpm@linux-foundation.org" , "hannes@cmpxchg.org" , "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" , Honggyu Kim Subject: Re: [PATCH 2/2] mm/damon/sysfs-schemes: add use_nodes_of_tier on sysfs-schemes Date: Fri, 30 May 2025 12:40:16 -0700 Message-Id: <20250530194016.51798-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7FBEF4000F X-Stat-Signature: if73sieugoddzuuubi6c9renmwt6guuk X-Rspam-User: X-HE-Tag: 1748634020-605635 X-HE-Meta: U2FsdGVkX1+m2otB0uwEezAr6hKFkeaYQ5NxcAvUFo7IpAY2kWE+wbyWCfWyRjK4OMZys2iRqAhmk6aZf8NcFLW+2Q9lkzDjfzeH1rjtgakjZZfMB0kcRDhJDLeg0oR4tZuS+dSqfFRVeX5IG7Ld9DuXdzVjSV1VT++pQt94g50Rf2T/dzxlwjMquSCyC0B1zvLuWFaQDuD6vImgQbkEBQIWMFlGD9+VjB1RgZ9dfhATlSEi0ekqbSfz92z8Bx7qSnp/Vlhkaf5jimcLuKI4DE/sw4r4kRYLYv/J2+SjgbUc5x6W8xPf8FLb9p3jiau2t5cuWxTEusHuTT9zYqiQXH/Ljvhi3QxQgJvj9Z0Jckh4pY/7HZz6Vzq+RXfqulwhBP5YJrtgDVExrSXKg2jqhGkA8xKJI6XyoFSdIRl8FSgYBjqhUwS3lcRXSEXS1/x1x1+wbljTiCygg2X+dNhjRx0wS65f8lfyGMDM0TFGJnnX1xUvAESlguXsghtL6IoWu6Gnpmn5tvNO37Rhv281YUx1JzMlWEwJQVKff/CgESfHiZbU/4pTu70AllJv9odIwoke8MBCmb73pDuR5KfH1agG1JgUjf0bTQFPqGT5dox+a2GDr2gJqBDGypiaHtoEtYuIGPxQTmD0otedLvNk5eimqZHJmFR3yzMROXvR6eB5lnbrsYM8vzNdSsbHDSKBG208wJu24figmA3oPxScka4wQ/C3dcsfHQcIy3b+W3caWdu95/dOn61oHP/Ndkdl8iiesRluG4U5JxaF6YUem/WbCm85vtyY7V7BEniLuvQ85EweTFCMbNJKIRCNPLgkRYaYuqauqKm1P5DQOXLwj4jC8FG3U5Fh5bif/puNhaJnK6K0n9n9WmgpQdGcL4qEwAEl/9K7bdNncVUkKmp5uUVyOK6v7V3WtO8YAGdgxaB0FS5dmNcR9Ycgp5P9NkJ7NEX33SJHPliWZpNk+g2 HzwsefUq KK5CvzgaU8RQq0B8vUVnxcDE7Wnio6FYfmbl+zENldSgryrZenTyCbZ+Hj3532OvPg9baLVHXwZl2M1uzFgAuSA2gaA5bCJXpNjL5YInPO2ipqTpAabobvtjUUuVS2/Hu65JhGfycP7qu/sKc+4mGIWLisQPfYMUXqYwopPcg46ViMJ7V8VBI0UpKT0WxmBpvvz8eAZsj/LjkrR0dqbOCQB4QO32WuJJHdh/4Zq1M7uPJ/wwmQ3a/gshH+s+/Y0BKww5opZC5hI+YQvTsZSNZ+Yhe9qY228b3p9bll6UyU+zWf7stiR5QwqDvNyWiMm5S/LuYuddYYm0R4oLD3HIIBKa5im73ngwFi0MWIQT/kFVCyLPdhpI1WuoYo2I9frJBg9S6RtvVfoTGBvVn5OUWX4LGoX2gy+wt9cXKiG96MGPyVWJtkCh2f9qhrw== 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, Thank you for continuing this important discussion. Before starting, though, seems your mail client is not setting 'In-Reply-To' field of your mails. For people who uses 'In-Reply-To' field based threads displaying tools, ths thread could be difficult to read the whole contents. Please consider using tools that set the field correctly if possible. You could get more information about available mailing tools from https://docs.kernel.org/process/email-clients.html Btw, I use hkml (https://docs.kernel.org/process/email-clients.html#hackermail-tui) ;) On Fri, 30 May 2025 08:04:42 +0000 Simon Wang (王传国) wrote: [...] > Your concern is that adding the bool use_nodes_of_tier variable and introducing > an additional parameter to multiple functions would cause ABI changes, correct?​​ You are correct. > > ​​I propose avoiding the creation of the 'use_nodes_of_tier' sysfs > file. Instead, we can modify the __damon_pa_migrate_folio_list() function to > change the allowed_mask from NODE_MASK_NONE to the full node mask of the > entire tier where the target_nid resides. This approach would be similar to > the implementation in commit 320080272892 ('mm/demotion: demote pages > according to allocation fallback order'). Then, this causes a behavior change, which we should not allow if it can be considered a regression. In other words, we could do this if it is a clear improvement. So, let's think about if your proposed change is an improvement. As the commit 320080272892 is nicely explaining, I think that it is an improved behavior for demotion. Actually it seems good behavior for promotion, too. But, the behavior we are discussing here is not for the demotion but general migration (specifically, DAMOS_MIGRATE_{HOT,COLD}). In my opinion, DAMOS_MIGRATE_{HOT,COLD} behavior should be somewhat similar to that of move_pages() syscall, to make its behavior easy to expect. So I think having commit 320080272892's behavior improvement to DAMOS_MIGRATE_{HOT,COLD} is not a right thing to do. And this asks me a question. Is current DAMOS_MIGRATE_{HOT,COLD} behavior similar to move_pages() syscall? Not really, since do_move_pages_to_node(), which is called from move_pages() syscall and calls migrate_pages() is setting mtc->nmask as NULL, while DAMOS_MIGRATE_{HOT,COLD} set it as NODE_MASK_NONE. Also, do_move_pages_to_node() uses alloc_migration_target() while DAMOS_MIGRATE_{HOT,COLD} uses alloc_migrate_folio(). I overlooked this different behavior while reviewing this code, sorry. And I don't think this difference is what we need to keep, unless there are good rasons that well documented. Thank you for let us find this, Simon. So I suggest to set mtc->nmask as NULL, and use alloc_migration_target() from __damon_pa_migrate_folio_list(), same to move_pages() system call. To use alloc_migrate_folio() from __damon_pa_migrate_folio_list(), we renamed it from alloc_demote_folio(), and made it none-static. If we use alloc_migration_target() from __damon_pa_migrate_folio_list(), there is no reason to keep the changes. Let's revert those too. Cc-ing Honggyu, who originally implemented the current behavior of __damon_pa_migrate(). Honggyu, could you please let us know if the above suggested changes are not ok for you? If Honggyu has no problem at the suggested change, Simon, would you mind doing that? I can also make the patches. I don't really care who do that. I just think someone should do that. This shouldn't be urgent real issue, in my opinion, though. > > I'd like to confirm two modification points with you: > ​​1.Regarding alloc_migrate_folio()​​: > Restoring the original nodemask and gfp_mask in this function is the correct approach, correct? I think that's correct, but let's discuss about the patch on the patch's thread. > ​​2.Regarding DAMON's migration logic​​: > The target scope should be expanded from a single specified node to the entire memory tier > (where the target node resides), correct? I don't think so, as abovely explained. > ​​Can we confirm these two points are agreed upon?​ I believe hope this is answered above. Thanks, SJ [...]