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 756CAC7114A for ; Fri, 13 Jun 2025 16:13:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 169D06B008A; Fri, 13 Jun 2025 12:13:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 141E06B008C; Fri, 13 Jun 2025 12:13:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07F906B0095; Fri, 13 Jun 2025 12:13:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DE0486B008A for ; Fri, 13 Jun 2025 12:13:11 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8FA0E1609C3 for ; Fri, 13 Jun 2025 16:13:11 +0000 (UTC) X-FDA: 83550871782.24.3C51435 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf28.hostedemail.com (Postfix) with ESMTP id A1280C0009 for ; Fri, 13 Jun 2025 16:13:09 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="D9Yd/3Cr"; spf=pass (imf28.hostedemail.com: domain of bijan311@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=bijan311@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749831189; 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=1+VwKYoq4K6K/5yHVH5q1Qz6OOz6+/W6hIZOp3rpGbI=; b=ZLYjEBr9PHE4x0+DLCvlL1UCd2viw1WAJ4FgMZGAOltNXtsOMSzTbDvDMUtTlhubT5RnXl mPKSbYjawqCiakzmvMpXhQhmg3B+hJK8Aog3ki1F9Yf25DPkCrY/1ivryi2HGSuNKW2n7N pL29ISn0RPzNIa+U6RG5MY6LxcEzgjs= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="D9Yd/3Cr"; spf=pass (imf28.hostedemail.com: domain of bijan311@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=bijan311@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749831189; a=rsa-sha256; cv=none; b=7b4MqlV9yo12atXbncKmtRNkS4jaoGqbgFSDcFJt9DH7VcYLcW7wTWMDc8g3dmgfhHu+iT Ee7+647GatjcCMB954IDTzpkgms4yKtePk05xEMdSkrTmcZOfB4QRAxaE1Y75R7c2hzaB1 EskaWr0QwtCatPJwZNBUmRT70jITvks= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-adb2bb25105so391395766b.0 for ; Fri, 13 Jun 2025 09:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749831188; x=1750435988; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1+VwKYoq4K6K/5yHVH5q1Qz6OOz6+/W6hIZOp3rpGbI=; b=D9Yd/3CrrafZkNOR/U7ZTDrm/jIxLbUpIssXkIcW97AW0tDVNsXQEJ68zjnMRSoIW1 ZUEgSKSPnhWrt48FiucS4DJMPYjeInLB9r9TCujjhnXOaHvGNs1k1aDdvFUMElz14QJu CB7oH9gBa/pHH3xNA/zvPpoxh/aTrCAh1ceD8e1/prZ8kMO9e/Gwx8moHFjVNajWTkcd c+hVDnbifyRE+Rn3wsAnyqLSiYhObhzO8nj4j2+xKZvDboqOnWfHw7rzAhMzrxH6KeiK emakfMO4nyFmB2tj0UGcuyFB1L65VYd2t8NyTu1YZkLlUwdcO+LJrBOg+P/8pEvzzHfx lMJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749831188; x=1750435988; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1+VwKYoq4K6K/5yHVH5q1Qz6OOz6+/W6hIZOp3rpGbI=; b=CN/s6xOPIUC36oJyHTr5gapSX7FgN+ZN9kcFXdEX84fm+y1N/G+4brhR6tG9PHI56F zUhoDSDN44Ts1RU9CL0Rf7l2vU5q16bargqUULrwI2F2IPgnJrB1+G/euw5aIGcaEUe+ IvFc62r4ZfauSFekhU2DoMClR2o760WH8+e7cQ5slhoXjupXBBk0JDGMnikZm1s+CU6C /NoCQUxl6xDhZjajfR2XwRyO5ivCdoPx72jX3A7SbBFWu/UXHAsdqvDG8SE4nQ4BzPda NZQbkjNXXCeQKyaBg8sBj3u5GZlNuXit6HPJCrZ6eDpXOlnuA0vsUTjJn+xcsEO7Y94a oRYw== X-Forwarded-Encrypted: i=1; AJvYcCWkoC9p+siFrG3DOuBq0TdxYZtlWlqpv48qarv2fUGrh+Le9XkHsgLtn/Jwhv4cZ1yApDa0ctW8Ew==@kvack.org X-Gm-Message-State: AOJu0YznZ/I//mzi0+by2pGD5n+F3wOGOH9F7M1ppKGfsiB72UVxSrfV KMSJfOm35uwXMpjnpuD9IpxL9580iktXrksHLFI5wvMN0e9Sk5nOUjhr/Puo9dgz9Kr0oMx+r14 4m5HElPCM8NefMae+o/En7aDR5hIBkpA= X-Gm-Gg: ASbGncveNQ7K7arzvpQApleYBI5pRAL5pxsFJiUQIGnHA3U3xJlaOVjLmbbNFlVLJG+ najz8N9TJsG4GKUokpxuYLANzgnrA951kJ2KBGP4jr0kA8VGvlUo/t/PR8iKECLmKzPJL3SjUrD Ca2Dd9LBJCX7AQ7RldeFimTjZYci6kxnuWnRfkaGZ9Zt8OJDFw/ETpSM+NZKWMmGTvYPHKeB4qX 14X X-Google-Smtp-Source: AGHT+IFfbm2ILbzNqaWeP+BPo+t/ZcGuAqPpA1yn78O51dNA9iM+X1CfAQz9tF1EH2JVkFqRrrq4xtngmwFGJQB2JJE= X-Received: by 2002:a17:907:970f:b0:ade:4339:9358 with SMTP id a640c23a62f3a-adec5622d75mr357900366b.22.1749831187984; Fri, 13 Jun 2025 09:13:07 -0700 (PDT) MIME-Version: 1.0 References: <20250612181330.31236-1-bijan311@gmail.com> <20250613095525.1845-1-rakie.kim@sk.com> In-Reply-To: <20250613095525.1845-1-rakie.kim@sk.com> From: Bijan Tabatabai Date: Fri, 13 Jun 2025 11:12:56 -0500 X-Gm-Features: AX0GCFvh-zD9qUo9qgFI77L0Qw-QGCNYqP0mhIl0FpPrr_nZ3onLg5ACPH5Ji9E Message-ID: Subject: Re: [RFC PATCH 0/4] mm/damon: Add DAMOS action to interleave data across nodes To: Rakie Kim Cc: sj@kernel.org, akpm@linux-foundation.org, corbet@lwn.net, david@redhat.com, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, bijantabatab@micron.com, venkataravis@micron.com, emirakhur@micron.com, ajayjoshi@micron.com, vtavarespetr@micron.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kernel_team@skhynix.com, damon@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A1280C0009 X-Stat-Signature: 1sy9kyd9chqe771z6ur7pgpgefixjk8i X-Rspam-User: X-HE-Tag: 1749831189-966639 X-HE-Meta: U2FsdGVkX186ZVbaEKxvGNRBS24/75f0ZfDkGVXtTaEAYqRnyoEOQRiR52njQEDLPV2WvALaNP6cYujYUGQgtYqp2SoDKAx6yilp8MguKmwrayTRu1Wvt51fl0N9VJjYiOFOfkl1c818Wvs8LdiJ6d1fMrqx86AgDwyLpSvfARIuK3rOXoJ4VnSfWgfRBUIjN6pk04h829k/QxmQOO6ClZxX0NJjQXUFVxnrBHjFFZci1wu+VbPjctgDjEdYwmWJF8/pQ/9oA5IqUm9f5HCRa+Uf6fE9Cv2zKQkQuObQvwHRhiT+QDo6b04fUc2ZHRQINYpEJFI8VmEYqzrkSSc0J1xJcBfe1fan2xk1QwrUino7fxaODfYeOwCXe06+lGsXd078juSF2/FOi1XfwfJTmTtGyVvHW1yc23q/EsFMY2Fmho7XeYnXsTVjeZgKDV89cWI6Mpc5sfVZZEYyKewo4Yl7oM7Ovt4SAE/mxRky0rMf+na4cn+0aB42jrPiUSM1cv4lXfC31RiJfto9IxmOkwaZj8N2VmFSzmIdwtohlwkiIcAJ9rKIlWfwZbBPEwS9Q60FAJqRDiq/hn/sAoI9c+yBJUnHoJSNo/txWiSRad5i0b+D2I46CVmMDkKRxqboequhbVScsXAl6KVCRx6Ke8pCI/kMWgkx/qtx7r95tXd3wWBJyWk3Yt3kyRSGk+lhrGcG9OzPwD7K4IjfJc3IB7CoDpTUzdT9hI9K/6N0LfJ7hkFFwqma5qCax7aPqSrg0Sf/A5SlztFwMJPjcfIbkJLIelJ47E2pxEmon3kNbxc4+EdIW4zWNEVRQODpZY1jYBYfzQnvI12jin/l53Q/EkehUXCQATG0tyViC9CML6t7rmBAmNzo01d2jvv4U5gWqJmaPMYVNdU3nkI/rfDo8u4qoIAB7oPLnocAYcbGOMJl5IPx2lo1hLKENJlBvFOOqucIUuBcxrrY66G/x/n jZJR5z1u w06MztwNjY335c5FLS24BE2DQbyP8+wAdK6rMEPd8PwOZpqEDOU6xGlbz0sc72Qtx+V3jQsXhZMK+QTPM/4W3pyEdZXKkCRSh/MHC1iUJRQyk+I5+D9pQpIKwD6EfgZZIHFAkiufBqPb92y38FH6hyJQ+8nkYai4sbg9bSgji26/Om2LMfhoHqm99wLn6zljCUypC3PJD/sbYSgYSBvivFi+O/PS3J269xqKJ6UJ9i3TJWqioNWT9Y+HyKbG87QM/DLk2clMFX8ACs2OYgOYx3UNi1lUjYno72gS1piVNwoWVgpNXTbBtvW2Kptl9KV4Eg+Zhm5bI1b2zrDnpBMnoWea1BCEUO73Frski7y7LGPxkZ1DvOb5V3w2sZ+K/I1BA5MAw/tqSCtlcqUkYOmf1endjUwgjVE6bNFSlGK7BMBiCknccRopCAnMffkTm7epomgLIy1+WWi5ze7D9zq/0TaMvDoaNe0rbisp1vJI5v4qcjZ5k4nX91UFLMwhslBHtaIzbFKJ8Wx+X4kHvHBDS6nXpbg== 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, Jun 13, 2025 at 4:55=E2=80=AFAM Rakie Kim wrote: > > On Thu, 12 Jun 2025 13:13:26 -0500 Bijan Tabatabai w= rote: > > From: Bijan Tabatabai > > > > A recent patch set automatically set the interleave weight for each nod= e > > according to the node's maximum bandwidth [1]. In another thread, the p= atch > > set's author, Joshua Hahn, wondered if/how these weights should be chan= ged > > if the bandwidth utilization of the system changes [2]. > > > > This patch set adds the mechanism for dynamically changing how applicat= ion > > data is interleaved across nodes while leaving the policy of what the > > interleave weights should be to userspace. It does this by adding a new > > DAMOS action: DAMOS_INTERLEAVE. We implement DAMOS_INTERLEAVE with both > > paddr and vaddr operations sets. Using the paddr version is useful for > > managing page placement globally. Using the vaddr version limits tracki= ng > > to one process per kdamond instance, but the va based tracking better > > captures spacial locality. > > Hi Bijan, > > Thank you for explaining the motivation and need behind this patch. > I believe it's important to consider the case where a new memory node > is added and the interleave weight values are recalculated. > > If a new memory node (say, node2) is added, there are two possible > approaches to consider. > > 1. Migrating pages to the newly added node2. > In this case, there is a potential issue where pages may be migrated > to node2, even though it is not part of the nodemask set by the user. > > 2. Ignoring the newly added node2 and continuing to use only the existing > nodemask for migrations. > However, if the weight values have been updated considering node2 > performance, avoiding node2 might reduce the effectiveness of using > Weighted Interleave. > > It would be helpful to consider these two options or explore other > possible solutions to ensure correctness. > > Rakie Hi Rakie, Thank you for the reply - this is not a problem I considered, but it is important. I think option 2 is the correct choice, and is what is already done by the policy_nodemask function we use to determine what node to place a page. I do not think it makes sense to ignore the nodemask when it is explicitly se= t by the user. However, if we decide to change the way we get the interleave weights to be= from a DAMON specific interface, then I think it would make sense to only migrate to the newly onlined node if the user sets a weight for that node. This is because in that case, the user is explicitly telling DAMON to use that node. Let me know if you have any other concerns, Bijan