From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6BDF51DB356; Sun, 5 Jul 2026 20:57:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783285075; cv=none; b=M7+3qCwmVTuYkF7YE+BJgLQxj7yZ+ui47m8TjMU/bzuwa/+IGCo181WSkl7PcVW+Xcr50BVIayvnjTgRctU0hM0Dm2Gx34rTX6EKMFIPb5MChkmaLuYw8BwTSg01oUdDjQEvduUitafw1nNuW24DUKECXPmq4E27hugvj+Nopr4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783285075; c=relaxed/simple; bh=5ik6sl9mHqWDKYisPOVkM7iZmcM6M56cebCfcj4siCw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=pwL6qhPtqiWEUT1InYP2qlS9fpTXKjvzALQhqjOc+ZaIFhPAO4PQNcnnHHgEeV0t+Q63KmkVxtGUIteffCAbf0hx7RnjLGK4mppAbYsXBlUbwK44++bIJab7RIM/mzM+jberQwBhKsA9uWdnDxfrlcM8FP583l6pnqS4Xa6xMYg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kMENlORB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kMENlORB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B00391F000E9; Sun, 5 Jul 2026 20:57:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783285073; bh=ljhXdB25UIMpi4HZYViOqTzfk2jkh8D136DetA33OqU=; h=From:To:Cc:Subject:Date; b=kMENlORBAwN/Tz4JK1FTBBlzpKfdbs6G0jbL+oKxWxOEnoCvPGvHKGaDvBLa3bzz7 fE9fikj1I+lwqpNRkhXUobSb/eNp0wVug0Cvd2bFHyG0RaJ2aHQ8hUjet8PgH0ZGts W/6Pu/WBw5do4XFu4IOfew6awh9GBvhVJqqNfgRDI6V3FPtS7/zhUaOpFJ6i2zKfWw mRxiktuQ+SGqm0ZpTYIFXO/NUQoG0CeI3fESubunWFIOILBBtsjwS06OjMFL6KqHq1 mhOlP/rT44jvZv4SsfzhHRR641V3q8i5Koyi2Ipd368urehsD/LBSWyHT5mYXCT8Dn FJnxFlr1zq8yg== From: SJ Park To: Cc: SJ Park , "Liam R. Howlett" , Andrew Morton , David Hildenbrand , Jonathan Corbet , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , damon@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 00/16] mm/damon: introduce data attributes only monitoring Date: Sun, 5 Jul 2026 13:57:22 -0700 Message-ID: <20260705205743.98656-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit TL;DR: Introduce a way to get DAMON's best effort accuracy monitoring of user-demanding non-access data attributes. Background ========== DAMON was initially designed for only access monitoring. It turned out users want to get the information together with more data attributes. For example, some users want to know how much of a hot memory region belongs to huge pages or specific cgroups. Page level properties based monitoring was introduced with commit 626ffabe67c2 ("mm/damon: clarify trying vs applying on damos_stat kernel-doc comment") to fill the gap. Because it works only at snapshot level and snapshot capturing in the mode can induce high overhead, commit 45c49d9fd608 ("mm/damon/core: introduce struct damon_probe") introduced data attributes monitoring. Data attributes monitoring treats the attributes as only additional and subordinate information. Data access monitoring is always turned on, and regions are adjusted for best accuracy of the access information. In some cases, users may be primarily interested in the attributes more than the access. They might even not care about the access information at all. Because DAMON treats data accesses as the only primary information, such users cannot get high quality attributes information. Design and Implementation ========================= Introduce another way for treating data attributes as the primary information. Add 'weight' property to each data attribute probe. When any of the weights are set, the mode is enabled. Data access monitoring is completely turned off in the mode. For region adjustment, the weighted sum of probe hit counters is used instead of the nr_accesses. Using the weights, users can specify to what attributes they are interested in to what degree. DAMON will adjust the regions and provide the best-effort quality monitoring that is optimized for the user demands. Extend damon_operations for efficient use of probe hits. Update regions merge and kdamond main logic to support the new mode. Add a new struct field and a sysfs file for API callers and ABI users, respectively. Test ==== On ~7 GiB memory idle system, run a simple AI-assisted program. The program allocates and faults 2 GiB anonymous pages. Then, it does nothing but wait until the user terminates it. Hence, the system ~2 GiB of anonymous pages with no active accesses. Monitor the distribution of the anonymous pages using DAMON attributes monitoring mode, using DAMON user-space tool, damo [1]. $ sudo ./damo start --probe_filter allow anon $ sudo ./damo report access --dont_merge_regions heatmap: 00000000000000000000000000000000000000000000000399999995111111146666666666666666 # min/max temperatures: -2,470,000,000, -1,620,000,000, column size: 99.800 MiB intervals: sample 5 ms aggr 100 ms (max access hz 200) # 0 4.000 KiB 79.840 MiB 0 hz 24.700 s 2 1 79.844 MiB 718.562 MiB 0 hz 24.700 s 8 2 798.406 MiB 793.148 MiB 0 hz 24.700 s 7 3 1.554 GiB 797.828 MiB 0 hz 24.700 s 7 4 2.333 GiB 794.668 MiB 0 hz 24.600 s 8 5 3.109 GiB 791.117 MiB 0 hz 24.500 s 0 6 3.882 GiB 785.312 MiB 0 hz 24 s 2 7 4.649 GiB 787.867 MiB 0 hz 16.200 s 6 8 5.418 GiB 784.477 MiB 0 hz 23.300 s 6 9 6.184 GiB 783.820 MiB 0 hz 18.200 s 9 10 6.950 GiB 797.730 MiB 0 hz 18.900 s 7 11 7.729 GiB 69.625 MiB 0 hz 18.900 s 0 memory bw estimate: 0 B per second total size: 7.797 GiB record DAMON intervals: sample 5 ms, aggr 100 ms Note that the line after the line starting with "intervals:" is not provided by the current version of 'damo'. I manually added the legends line for easier understanding of these results. Each of the 12 lines after the legend line shows the DAMON-found regions. Each line shows 1) index of the region, 2) start address of the region, 3) size of the region, 4) access frequency of the region, 5) age (how long the access frequency on the region was kept) of the region, and finally 6) the probe hit count. Because data access is the primary information that adjusts region for, and there is only nearly zero access on the system, regions are naively adjusted with the same size. Still show different distribution of the anonymous pages, but it is obviously very rough information. Switch to the attributes only mode and show how it changes the picture: $ sudo ./damo tune --probe_filter allow anon --probe_weight 100 $ sudo ./damo report access --dont_merge_regions heatmap: 88888888888888888889888999999889999999000004888888888888889999988888898888888888 # min/max temperatures: -4,430,000,000, 0, column size: 99.800 MiB intervals: sample 5 ms aggr 100 ms (max access hz 200) # 0 4.000 KiB 60.445 MiB 0 hz 700 ms 0 1 60.449 MiB 1.363 MiB 0 hz 600 ms 18 2 61.812 MiB 144.000 KiB 0 hz 0 ns 1 3 61.953 MiB 1.922 MiB 0 hz 2.400 s 19 4 63.875 MiB 12.133 MiB 0 hz 200 ms 0 [...] 500 5.132 GiB 8.000 KiB 0 hz 2 m 15.800 s 20 501 5.132 GiB 8.000 KiB 0 hz 2 m 16.200 s 0 502 5.132 GiB 16.000 KiB 0 hz 2 m 16.900 s 20 503 5.132 GiB 24.000 KiB 0 hz 2 m 14.200 s 0 504 5.132 GiB 8.000 KiB 0 hz 2 m 14.900 s 20 [...] 923 7.534 GiB 126.637 MiB 0 hz 0 ns 6 924 7.658 GiB 252.000 KiB 0 hz 54.800 s 20 925 7.658 GiB 142.242 MiB 0 hz 300 ms 0 memory bw estimate: 0 B per second total size: 7.797 GiB record DAMON intervals: sample 5 ms, aggr 100 ms As expected, regions are adjusted to provide the best accurate picture for the anonymous pages distribution (). The region 0 (60.445 MiB memory from the address 4.000 KiB) has nearly zero anonymous pages. The region 1 (1.363 MiB memory from the address 60.449 MiB) is nearly full with anonymous pages. Region 500 (8 KiB memory from the address 5.132 GiB) is certainly two anonymous pages. Future Work =========== Attributes only monitoring disables access monitoring. We will enable that in future, by extending the supported attributes to include data accesses. This patch series, and the future work are parts of the ongoing project [2] for extending DAMON. The project aims to extend DAMON with primitives other than page table accessed bits such as AMD IBS, Intel PEBS, and Arm SPE, to provide more powerful and detailed information like per-CPUs/threads/reads/writes monitoring. Patches Sequence ================ Patch 1 introduces damon_probe->weight for specifying the weights of each attribute. Patches 2-6 extends apply_probe() damon_ops callback to efficiently support the new mode. Patch 7 extends regions merge function to work with probe hits in the mode. Patch 7 also introduces the function for detecting the mode enablement but always returns false, for safe and incremental changes. Patches 8-11 incrementally update kdamond_fn() to support the mode. Patch 12 completes the mode detection function implementation, so that the new mode really works. Patch 13 introduces a new sysfs file for ABI users. Finally, patches 14-16 respectively updates design, usage and ABI documents for the new feature and interfaces. [1] https://github.com/damonitor/damo [2] https://lore.kernel.org/20260525225208.1179-1-sj@kernel.org/ SJ Park (16): mm/damon/core: introduce damon_probe->weight mm/damon/core: ask apply_probes() ops callback to set sampling address mm/damon/paddr: set samples in apply_probes() if requested mm/damon/core: ask apply_probe() to return max probe hits weighted sum mm/damon/core: implement damon_probe_hits_wsum() mm/damon/paddr: respect return_max_wsum mm/damon/core: extend merge function to work with probe hits mm/damon/core: disable access monitoring when probe weights are set mm/damon/core: set samples in apply_probes() if probe weights are set mm/damon/core: s/max_nr_accesses/max_merge_score/ in kdamond_fn() mm/damon/core: get merge threshold from probe hits when weights are set mm/damon/core: implement damon_has_probe_weight() mm/damon/sysfs: implement probe/weight file Docs/mm/damon/design: document attrs-only monitoring Docs/admin-guide/mm/damon/usage: document weight sysfs file Docs/ABI/damon: document probe weight file .../ABI/testing/sysfs-kernel-mm-damon | 6 + Documentation/admin-guide/mm/damon/usage.rst | 11 +- Documentation/mm/damon/design.rst | 25 ++++ include/linux/damon.h | 11 +- mm/damon/core.c | 107 +++++++++++++++--- mm/damon/paddr.c | 11 +- mm/damon/sysfs.c | 25 ++++ mm/damon/tests/core-kunit.h | 13 ++- 8 files changed, 184 insertions(+), 25 deletions(-) base-commit: 3783e23372c397a29574c34283e1f07aa420db74 -- 2.47.3