From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f68.google.com (mail-dl1-f68.google.com [74.125.82.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 288BD329C4F for ; Thu, 29 Jan 2026 21:58:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769723901; cv=none; b=tNv82UOg5zSCOvIrHrLtZU2267Iw5xl01Rf7TG7iap8YRI4QA/Qqxg8iWJT/EVwaqBugjtjfFTICS6PnojrEbdbfrnVcWf2NWI5trW/Ycn4FOUrHmj3D4CuS/aQauVSjReIJFb2qSp2W0q9huZd8Kk9x+WYFfeWhCnHNUO49CPM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769723901; c=relaxed/simple; bh=fy8EK8PWQZsqSffsYil7YART3hXT+T+mHqmJlgR9iak=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=onvY1Blcz16RoUwm0safZFPNwceBzJkZ4d4uahctYTun02TBTsc5Z7vM0MU8IilDFgiTf1thRVVRTf5J8xiQstxm7uZ4lIymS2oIZ8AdC83kt/+0cS7uBI16kfrLwYxMQdesMkj4owzmO0mcCXLWbek+2Fx06Cy6MaXf5fgrmIk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S92czNi+; arc=none smtp.client-ip=74.125.82.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S92czNi+" Received: by mail-dl1-f68.google.com with SMTP id a92af1059eb24-124b117776fso1210449c88.0 for ; Thu, 29 Jan 2026 13:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769723899; x=1770328699; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=C7ZtJvE3dpFWqwjZMa9omEQRwNhNuc19ZVJnJ8avCkY=; b=S92czNi+H451hgemOy+W5F1/y4kf5iqH5bpIibV/Ej1PVo4uXenK5tG0hcZp9Qtb57 4fowGgde1H6EdC3GgaIFUvnmqRxMVNDFXTGmFYaRftUR9iOid7e2Sn56UHKiXnerPVqz 8nQeEZTZP4Uso9D/8Gf+Ds5JQ3uW/PHH4ENdYKm/ReTujTAkg4Gkyt2Y/Pav4XucxhnX MxFxBL8AR8uRkdxFwOuUNqZdAxD09PmJe68Bk8XMXwIr7/o2I6gKNJpSpQh6y5+BZktY J4Moxf6m/WZqLVfPTgtTT9/ZN8vrtZ8le5I+4KGRC+XHn+eR9S7nuvuvF6cWFW0MFrVg Buww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769723899; x=1770328699; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=C7ZtJvE3dpFWqwjZMa9omEQRwNhNuc19ZVJnJ8avCkY=; b=wwTnj7uQM+L+WinLg9gZM46fx1RP4v3Dp7vkC06re9WqR4gFq0c9wJwrSCvvQlKmdk fHWDJJI26yTzzv4BtuYFoqtK4u20hwlNa19jpFSV8oOq7xcHYbHGGn7VsvcUywR3I3Xd 9IcDVHG73W5B+eWpQMbeKWFw8H0U01nCLiQSXiKaoxdslhUenRgtpvoa/haqKxESDtuC 9yN9VExKOR6u9MMs0ukatiYsM0xwcHIVCgyNA6lYwD78Ek99RB4ytM6iMZi939vI4e0D a/UTCTgOM2Ffir6sf/p0C3HodMB5kt8/NsvcoyqhUCBwrHwY5jtZrjYMyk4sjmqB5Si4 Pn2g== X-Forwarded-Encrypted: i=1; AJvYcCVMAG/0/AAAx6QuYLQwNhClO6vp53msAiZaJ+A5CbtnYeLbq6Cgl45EPEYdFY9C5v80/Tcu+4neuOoTkug=@vger.kernel.org X-Gm-Message-State: AOJu0YzKx6PMTqCL3UNvL0QAZIYDxGLQzK+avWHn37rWKRxLmq9qwlzq bDVHJvm+8ZNV1bnf/XiJ87k18NLyE/wC9f0twvXcUmp4UAIkCfKxQiQ= X-Gm-Gg: AZuq6aLEM1QeAxbrj2M+E6en63+EbV8eMoXKGkAdhTUz/peWFdL814mudASWJdl40IU RM76ltrAOH42ph3qSBXCRZ7zDiKLT+deUrr7aQhPYKzmAO94IBOnLXYov4csOXiSwuD94oEKrw4 FtGZ08DATycKcB5zgVB2dedUx14KkxhQRFOpgbbA0u8VtF5U3X4oF3qDxls6Yrqo93y+e9WfjHm avEgwV7nTjmJo6ua/p9CtWSSTSGpMYTJILb47VPS+cByvoy3XsTaFh/dYNcKbByILaPe95RcliW xW/BzLvXsw1BobC0hpVTyV1qQUkJv3bxhK5gK3IhuUd1YLXXDV3S6VciEAM3xDJj6TntXeib1Pz XC28WXfe7xX/GUOO4CxE2MidN4YzltWj0MGPb1nM9XoSMrLFGjc+ktn74HyrF+WBHrlLaC+rkXa 6i/1zdSxXm3w== X-Received: by 2002:a05:7022:68aa:b0:124:a610:62f6 with SMTP id a92af1059eb24-125c1006e73mr427951c88.44.1769723899034; Thu, 29 Jan 2026 13:58:19 -0800 (PST) Received: from localhost ([137.201.204.52]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b7a1af8a7bsm8593035eec.34.2026.01.29.13.58.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jan 2026 13:58:18 -0800 (PST) From: Ravi Jonnalagadda To: sj@kernel.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Cc: akpm@linux-foundation.org, corbet@lwn.net, bijan311@gmail.com, ajayjoshi@micron.com, honggyu.kim@sk.com, yunjeong.mun@sk.com, Ravi Jonnalagadda Subject: [RFC PATCH v2 0/3] mm/damon: Introduce node_target_mem_bp Quota Goal Metric Date: Thu, 29 Jan 2026 13:58:11 -0800 Message-ID: <20260129215814.1618-1-ravis.opensrc@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series introduces a new DAMON quota goal metric, `node_target_mem_bp`, designed for controlling memory migration in heterogeneous memory systems (e.g., DRAM and CXL memory tiering). v1: https://lore.kernel.org/linux-mm/20260123045733.6954-1-ravis.opensrc@gmail.com/T/#u Changes since v1: ================= - Renamed metric from `node_sys_bp` to `node_target_mem_bp` for consistency with existing node-related quota goal metrics (node_mem_used_bp, node_mem_free_bp) as suggested by SJ. - Fixed the metric calculation: * Numerator: Now correctly counts only scheme-eligible bytes (regions matching the scheme's access pattern criteria). * Denominator: Now uses node capacity instead of total system memory. - Removed the get_goal_metric() ops callback. The implementation now resides in core.c, following the existing pattern for other metrics that have ops-layer dependencies. - Removed the early-exit optimization patch. As SJ noted, this would introduce a behavioral change for existing users and should be an opt-in feature with a properly designed interface. This can be addressed in a separate follow-up series. - Removed capacity clamping logic (was tied to early-exit behavior). Background and Motivation ========================= A previous patch series [1] added weighted interleave support for DAMON migrate_{hot,cold} actions for vaddr schemes. That approach requires VMA offset information to determine target nodes, which for paddr schemes would require costly rmap walks. This series takes a different approach for PA-based migration control using basis points (bp) target-state goals instead of weight-based action rates, avoiding the need for rmap walks entirely. What This Metric Does ===================== The `node_target_mem_bp` metric measures: scheme_eligible_bytes_on_node / node_capacity expressed in basis points (bp, 1/10000). "Scheme-eligible bytes" are regions that match the scheme's access pattern criteria (size, nr_accesses, age). This allows users to specify goals like: "Migrate hot pages until node N contains X% hot memory" Unlike weight-based approaches that specify ACTION RATES, this metric specifies a TARGET STATE, which naturally prevents oscillation issues that would occur with weight-based PA migration without rmap. Two-Context Setup for Hot Page Distribution =========================================== For distributing hot pages between two NUMA nodes (e.g., DRAM node 0 and CXL node 1), two DAMON contexts work together: Context 0: monitors node 0, migrate_hot -> node 1 goal: node_target_mem_bp, nid=0, target=6000 "Migrate hot pages out when node 0 exceeds 60% hot" Context 1: monitors node 1, migrate_hot -> node 0 goal: node_target_mem_bp, nid=1, target=4000 "Migrate hot pages out when node 1 exceeds 40% hot" Each context migrates excess hot pages to the other node. The system converges when both nodes reach their target hot memory ratios. Complementary to Existing vaddr Migration ========================================= This series complements rather than replaces the vaddr weighted interleave migration: vaddr migration (weight-based): - Per-process control - Fine-grained interleave patterns via VMA offset - Deterministic placement based on weights paddr migration (bp-based, this series): - System-wide control - Target-state goals for node capacity management - No rmap overhead Patch Organization ================== 1. mm/damon/core: add DAMOS_QUOTA_NODE_TARGET_MEM_BP metric - Adds new enum value and documentation 2. mm/damon/core: implement NODE_TARGET_MEM_BP metric calculation - Adds damos_get_node_target_mem_bp() function - Updates function signatures to pass ctx and scheme through call chain 3. mm/damon/sysfs-schemes: expose NODE_TARGET_MEM_BP metric - Exposes metric as 'node_target_mem_bp' in sysfs Status ====== These patches have been compile-tested but have NOT been tested on actual hardware. Feedback on the design and approach is appreciated. References ========== [1] mm/damon/vaddr: Allow interleaving in migrate_{hot,cold} actions https://lore.kernel.org/linux-mm/20250709005952.17776-1-bijan311@gmail.com/ Ravi Jonnalagadda (3): mm/damon/core: add DAMOS_QUOTA_NODE_TARGET_MEM_BP metric mm/damon/core: implement NODE_TARGET_MEM_BP metric calculation mm/damon/sysfs-schemes: expose NODE_TARGET_MEM_BP metric include/linux/damon.h | 5 +++ mm/damon/core.c | 66 +++++++++++++++++++++++++++++++++++----- mm/damon/sysfs-schemes.c | 5 +++ 3 files changed, 69 insertions(+), 7 deletions(-) -- 2.43.0