[RFC PATCH 00/16] mm/damon: introduce data attributes only monitoring

[RFC PATCH 00/16] mm/damon: introduce data attributes only monitoring

[SJ Park]

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)
    #   <start>      <size>       <freq> <age>         <probe hits>
    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 <probe hits> 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)
    #   <start>      <size>       <freq> <age>         <probe hits>
    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 (<probe hits>).  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

[RFC PATCH 01/16] mm/damon/core: introduce damon_probe->weight

[SJ Park]

Add a new field, weight to damon_probe struct.  The field is used to
specify the degree of the API caller's interest to the data attribute
of the probe.

Signed-off-by: SJ Park <sj@kernel.org>
---
 include/linux/damon.h | 1 +
 mm/damon/core.c       | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 19b7e839bde0b..c9c1de7ec0e7b 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -764,6 +764,7 @@ struct damon_filter {
  * @list:	Siblings list.
  */
 struct damon_probe {
+	unsigned int weight;
 	struct list_head filters;
 	struct list_head list;
 };
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 390e00b3685ef..ca5c3f3e45fc6 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -166,6 +166,7 @@ struct damon_probe *damon_new_probe(void)
 	p = kmalloc_obj(*p);
 	if (!p)
 		return NULL;
+	p->weight = 0;
 	INIT_LIST_HEAD(&p->filters);
 	INIT_LIST_HEAD(&p->list);
 	return p;
@@ -1641,6 +1642,7 @@ static int damon_commit_probes(struct damon_ctx *dst, struct damon_ctx *src)
 	damon_for_each_probe_safe(dst_probe, next, dst) {
 		src_probe = damon_nth_probe(i++, src);
 		if (src_probe) {
+			dst_probe->weight = src_probe->weight;
 			err = damon_commit_filters(dst_probe, src_probe);
 			if (err)
 				return err;
@@ -1657,6 +1659,7 @@ static int damon_commit_probes(struct damon_ctx *dst, struct damon_ctx *src)
 		if (!new_probe)
 			return -ENOMEM;
 		damon_add_probe(dst, new_probe);
+		new_probe->weight = src_probe->weight;
 		err = damon_commit_filters(new_probe, src_probe);
 		if (err)
 			return err;
-- 
2.47.3

[RFC PATCH 02/16] mm/damon/core: ask apply_probes() ops callback to set sampling address

[SJ Park]

prepare_access_checks() DAMON ops callback sets the monitoring sampling
address per region.  In future, DAMON will be able to call only
apply_probes().  In this case, applyy_probes() may need to do the
sampling address setup, to minimize unnecessary regions iteration.
Update the protocol for the request.

Signed-off-by: SJ Park <sj@kernel.org>
---
 include/linux/damon.h | 5 +++--
 mm/damon/core.c       | 2 +-
 mm/damon/paddr.c      | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index c9c1de7ec0e7b..4dec5d314c782 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -647,7 +647,8 @@ enum damon_ops_id {
  * It should also return max number of observed accesses that made as a result
  * of its update.  The value will be used for regions adjustment threshold.
  * @apply_probes should apply the data attribute probes to each region and
- * accordingly update the probe hits counter of the region.
+ * accordingly update the probe hits counter of the region.  It should also
+ * &set sampling_addr or each region if &set_samples is true.
  * @get_scheme_score should return the priority score of a region for a scheme
  * as an integer in [0, &DAMOS_MAX_SCORE].
  * @apply_scheme is called from @kdamond when a region for user provided
@@ -665,7 +666,7 @@ struct damon_operations {
 	void (*update)(struct damon_ctx *context);
 	void (*prepare_access_checks)(struct damon_ctx *context);
 	unsigned int (*check_accesses)(struct damon_ctx *context);
-	void (*apply_probes)(struct damon_ctx *context);
+	void (*apply_probes)(struct damon_ctx *context, bool set_samples);
 	int (*get_scheme_score)(struct damon_ctx *context,
 			struct damon_region *r, struct damos *scheme);
 	unsigned long (*apply_scheme)(struct damon_ctx *context,
diff --git a/mm/damon/core.c b/mm/damon/core.c
index ca5c3f3e45fc6..7c0184cb78a50 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3675,7 +3675,7 @@ static int kdamond_fn(void *data)
 		if (ctx->ops.check_accesses)
 			max_nr_accesses = ctx->ops.check_accesses(ctx);
 		if (ctx->ops.apply_probes)
-			ctx->ops.apply_probes(ctx);
+			ctx->ops.apply_probes(ctx, false);
 
 		if (time_after_eq(ctx->passed_sample_intervals,
 					next_aggregation_sis)) {
diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
index 6172464981730..b13bf7c6eade3 100644
--- a/mm/damon/paddr.c
+++ b/mm/damon/paddr.c
@@ -166,7 +166,7 @@ static bool damon_pa_filter_pass(phys_addr_t pa, struct folio *folio,
 	return pass;
 }
 
-static void damon_pa_apply_probes(struct damon_ctx *ctx)
+static void damon_pa_apply_probes(struct damon_ctx *ctx, bool set_samples)
 {
 	struct damon_target *t;
 	struct damon_region *r;
-- 
2.47.3

[RFC PATCH 03/16] mm/damon/paddr: set samples in apply_probes() if requested

[SJ Park]

apply_probe() callback implementation in DAMON_PADDR is ignoring
set_samples parameter.  Respect it.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/paddr.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
index b13bf7c6eade3..ff4fcca949660 100644
--- a/mm/damon/paddr.c
+++ b/mm/damon/paddr.c
@@ -178,6 +178,10 @@ static void damon_pa_apply_probes(struct damon_ctx *ctx, bool set_samples)
 			phys_addr_t pa;
 			struct folio *folio;
 
+			if (set_samples)
+				r->sampling_addr = damon_rand(ctx, r->ar.start,
+						r->ar.end);
+
 			pa = damon_pa_phys_addr(r->sampling_addr,
 					ctx->addr_unit);
 			folio = damon_get_folio(PHYS_PFN(pa));
-- 
2.47.3

[RFC PATCH 04/16] mm/damon/core: ask apply_probe() to return max probe hits weighted sum

[SJ Park]

check_accesses() DAMON ops callback returns the maximum nr_accesses of
regions.  DAMON core uses it to calculate a reasonable region merge
threshold.  The core will need to adjust regions for not nr_accesses but
probe hits weighted sum in future.  For that, the core needs to know the
maximum weighted sum of the regions.  Update the protocol for the task.

Signed-off-by: SJ Park <sj@kernel.org>
---
 include/linux/damon.h | 7 +++++--
 mm/damon/core.c       | 2 +-
 mm/damon/paddr.c      | 4 +++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 4dec5d314c782..62caa67a3c40c 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -648,7 +648,9 @@ enum damon_ops_id {
  * of its update.  The value will be used for regions adjustment threshold.
  * @apply_probes should apply the data attribute probes to each region and
  * accordingly update the probe hits counter of the region.  It should also
- * &set sampling_addr or each region if &set_samples is true.
+ * &set sampling_addr or each region if &set_samples is true.  It should also
+ * return maximum probe hits weighted sum of regions if &return_max_wsum is
+ * true.
  * @get_scheme_score should return the priority score of a region for a scheme
  * as an integer in [0, &DAMOS_MAX_SCORE].
  * @apply_scheme is called from @kdamond when a region for user provided
@@ -666,7 +668,8 @@ struct damon_operations {
 	void (*update)(struct damon_ctx *context);
 	void (*prepare_access_checks)(struct damon_ctx *context);
 	unsigned int (*check_accesses)(struct damon_ctx *context);
-	void (*apply_probes)(struct damon_ctx *context, bool set_samples);
+	unsigned int (*apply_probes)(struct damon_ctx *context,
+			bool set_samples, bool return_max_wsum);
 	int (*get_scheme_score)(struct damon_ctx *context,
 			struct damon_region *r, struct damos *scheme);
 	unsigned long (*apply_scheme)(struct damon_ctx *context,
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 7c0184cb78a50..e42f512d87a11 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3675,7 +3675,7 @@ static int kdamond_fn(void *data)
 		if (ctx->ops.check_accesses)
 			max_nr_accesses = ctx->ops.check_accesses(ctx);
 		if (ctx->ops.apply_probes)
-			ctx->ops.apply_probes(ctx, false);
+			ctx->ops.apply_probes(ctx, false, false);
 
 		if (time_after_eq(ctx->passed_sample_intervals,
 					next_aggregation_sis)) {
diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
index ff4fcca949660..3eba3564a31fc 100644
--- a/mm/damon/paddr.c
+++ b/mm/damon/paddr.c
@@ -166,7 +166,8 @@ static bool damon_pa_filter_pass(phys_addr_t pa, struct folio *folio,
 	return pass;
 }
 
-static void damon_pa_apply_probes(struct damon_ctx *ctx, bool set_samples)
+static unsigned int damon_pa_apply_probes(struct damon_ctx *ctx,
+		bool set_samples, bool return_max_wsum)
 {
 	struct damon_target *t;
 	struct damon_region *r;
@@ -194,6 +195,7 @@ static void damon_pa_apply_probes(struct damon_ctx *ctx, bool set_samples)
 				folio_put(folio);
 		}
 	}
+	return 0;
 }
 
 /*
-- 
2.47.3

[RFC PATCH 05/16] mm/damon/core: implement damon_probe_hits_wsum()

[SJ Park]

When damon_probe->weight is set, the weighted sum of probe hits will be
useful.  It will be useful for not only the users but also DAMON
internal logics like regions merging.  Implement a function for
calculating it.

Signed-off-by: SJ Park <sj@kernel.org>
---
 include/linux/damon.h |  2 ++
 mm/damon/core.c       | 24 ++++++++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 62caa67a3c40c..c43986a3aa16c 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -1011,6 +1011,8 @@ unsigned int damon_nr_accesses_mvsum(struct damon_region *r,
 		struct damon_ctx *ctx);
 unsigned char damon_probe_hits_mvsum(int probe_idx, struct damon_region *r,
 		struct damon_ctx *ctx);
+unsigned int damon_probe_hits_wsum(struct damon_region *r, bool last,
+		struct damon_ctx *ctx);
 
 int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges,
 		unsigned int nr_ranges, unsigned long min_region_sz);
diff --git a/mm/damon/core.c b/mm/damon/core.c
index e42f512d87a11..d7d1e27d767eb 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -390,6 +390,30 @@ static bool damon_is_last_region(struct damon_region *r,
 	return list_is_last(&r->list, &t->regions_list);
 }
 
+/**
+ * damon_probe_hits_wsum() - Returns probe hits weighted sum of a region.
+ * @r:		region to get the weigted sum of.
+ * @last:	if the request is for last-window agggregated probe hits.
+ * @ctx:	context of &r.
+ *
+ * Return: the weighted sum of probe hits of the region.
+ */
+unsigned int damon_probe_hits_wsum(struct damon_region *r, bool last,
+		struct damon_ctx *ctx)
+{
+	struct damon_probe *probe;
+	unsigned int sum = 0;
+	int i = 0;
+
+	damon_for_each_probe(probe, ctx) {
+		if (last)
+			sum += r->last_probe_hits[i++] * probe->weight;
+		else
+			sum += r->probe_hits[i++] * probe->weight;
+	}
+	return sum;
+}
+
 /*
  * Check whether a region is intersecting an address range
  *
-- 
2.47.3

[RFC PATCH 06/16] mm/damon/paddr: respect return_max_wsum

[SJ Park]

apply_probes() ops implementation in DAMON_PADDR is ignoring
return_max_wsum.  Respect it.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/paddr.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
index 3eba3564a31fc..b85f88a7a38f4 100644
--- a/mm/damon/paddr.c
+++ b/mm/damon/paddr.c
@@ -172,6 +172,7 @@ static unsigned int damon_pa_apply_probes(struct damon_ctx *ctx,
 	struct damon_target *t;
 	struct damon_region *r;
 	struct damon_probe *p;
+	unsigned int max_wsum = 0;
 
 	damon_for_each_target(t, ctx) {
 		damon_for_each_region(r, t) {
@@ -182,7 +183,6 @@ static unsigned int damon_pa_apply_probes(struct damon_ctx *ctx,
 			if (set_samples)
 				r->sampling_addr = damon_rand(ctx, r->ar.start,
 						r->ar.end);
-
 			pa = damon_pa_phys_addr(r->sampling_addr,
 					ctx->addr_unit);
 			folio = damon_get_folio(PHYS_PFN(pa));
@@ -193,9 +193,12 @@ static unsigned int damon_pa_apply_probes(struct damon_ctx *ctx,
 			}
 			if (folio)
 				folio_put(folio);
+			if (return_max_wsum)
+				max_wsum = max(damon_probe_hits_wsum(r, false,
+							ctx), max_wsum);
 		}
 	}
-	return 0;
+	return max_wsum;
 }
 
 /*
-- 
2.47.3

[RFC PATCH 07/16] mm/damon/core: extend merge function to work with probe hits

[SJ Park]

When probe weights are set, users may want DAMON monitoring results to
be optimized for the weights.  For that, regions adjustment should work
for the weighted sum of probe hits.  Extend damon_merge_regions_of() to
detect if the weights are set, and work with probe hits in the case.

The weights setup detection function is incomplete.  It always returns
false.  It is intentional, so that more changes to completely support
weights can be made in an incremental but safe way.  Until the function
is completed, all changes depend on it is no-op, so DAMON works in the
current mode.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c             | 48 +++++++++++++++++++++++++++++--------
 mm/damon/tests/core-kunit.h | 13 ++++++++--
 2 files changed, 49 insertions(+), 12 deletions(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index d7d1e27d767eb..9bb884ab135ec 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -209,6 +209,11 @@ static struct damon_probe *damon_nth_probe(int n, struct damon_ctx *ctx)
 	return NULL;
 }
 
+static bool damon_has_probe_weights(struct damon_ctx *c)
+{
+	return false;
+}
+
 /*
  * damon_mvsum() - Returns pseudo moving sum value for a time window.
  * @current_nr:		The value of the current aggregation window.
@@ -3231,6 +3236,16 @@ static void damon_merge_two_regions(struct damon_target *t,
 	damon_destroy_region(r, t);
 }
 
+static unsigned int damon_merge_score(struct damon_region *r, bool last,
+		struct damon_ctx *ctx, bool use_probe_hits)
+{
+	if (use_probe_hits)
+		return damon_probe_hits_wsum(r, last, ctx);
+	if (last)
+		return r->last_nr_accesses;
+	return r->nr_accesses;
+}
+
 /*
  * Merge adjacent regions having similar access frequencies
  *
@@ -3239,24 +3254,37 @@ static void damon_merge_two_regions(struct damon_target *t,
  * sz_limit	size upper limit of each region
  */
 static void damon_merge_regions_of(struct damon_target *t, unsigned int thres,
-				   unsigned long sz_limit)
+		unsigned long sz_limit, struct damon_ctx *ctx)
 {
 	struct damon_region *r, *prev = NULL, *next;
+	bool use_probe_hits = damon_has_probe_weights(ctx);
 
 	damon_for_each_region_safe(r, next, t) {
-		if (abs(r->nr_accesses - r->last_nr_accesses) > thres)
+		unsigned int score, last_score;
+
+		score = damon_merge_score(r, false, ctx, use_probe_hits);
+		last_score = damon_merge_score(r, true, ctx, use_probe_hits);
+
+		if (abs(score - last_score) > thres)
 			r->age = 0;
-		else if ((r->nr_accesses == 0) != (r->last_nr_accesses == 0))
+		else if ((score == 0) != (last_score == 0))
 			r->age = 0;
 		else
 			r->age++;
 
-		if (prev && prev->ar.end == r->ar.start &&
-		    abs(prev->nr_accesses - r->nr_accesses) <= thres &&
-		    damon_sz_region(prev) + damon_sz_region(r) <= sz_limit)
-			damon_merge_two_regions(t, prev, r);
-		else
-			prev = r;
+		if (!prev)
+			goto set_prev_continue;
+		if (prev->ar.end != r->ar.start)
+			goto set_prev_continue;
+		if (abs(damon_merge_score(prev, false, ctx, use_probe_hits) -
+					score) > thres)
+			goto set_prev_continue;
+		if (damon_sz_region(prev) + damon_sz_region(r) > sz_limit)
+			goto set_prev_continue;
+		damon_merge_two_regions(t, prev, r);
+		continue;
+set_prev_continue:
+		prev = r;
 	}
 }
 
@@ -3289,7 +3317,7 @@ static void kdamond_merge_regions(struct damon_ctx *c, unsigned int threshold,
 	do {
 		nr_regions = 0;
 		damon_for_each_target(t, c) {
-			damon_merge_regions_of(t, threshold, sz_limit);
+			damon_merge_regions_of(t, threshold, sz_limit, c);
 			nr_regions += damon_nr_regions(t);
 		}
 		threshold = max(1, threshold * 2);
diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
index 0124f83b39b83..fe948000b72cf 100644
--- a/mm/damon/tests/core-kunit.h
+++ b/mm/damon/tests/core-kunit.h
@@ -226,6 +226,7 @@ static struct damon_region *__nth_region_of(struct damon_target *t, int idx)
 
 static void damon_test_merge_regions_of(struct kunit *test)
 {
+	struct damon_ctx *ctx;
 	struct damon_target *t;
 	struct damon_region *r;
 	unsigned long sa[] = {0, 100, 114, 122, 130, 156, 170, 184, 230};
@@ -236,20 +237,27 @@ static void damon_test_merge_regions_of(struct kunit *test)
 	unsigned long eaddrs[] = {112, 130, 156, 170, 230, 10170};
 	int i;
 
+	ctx = damon_new_ctx();
+	if (!ctx)
+		kunit_skip(test, "ctx alloc fail");
+
 	t = damon_new_target();
-	if (!t)
+	if (!t) {
+		damon_destroy_ctx(ctx);
 		kunit_skip(test, "target alloc fail");
+	}
 	for (i = 0; i < ARRAY_SIZE(sa); i++) {
 		r = damon_new_region(sa[i], ea[i]);
 		if (!r) {
 			damon_free_target(t);
+			damon_destroy_ctx(ctx);
 			kunit_skip(test, "region alloc fail");
 		}
 		r->nr_accesses = nrs[i];
 		damon_add_region(r, t);
 	}
 
-	damon_merge_regions_of(t, 9, 9999);
+	damon_merge_regions_of(t, 9, 9999, ctx);
 	/* 0-112, 114-130, 130-156, 156-170, 170-230, 230-10170 */
 	KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 6u);
 	for (i = 0; i < 6; i++) {
@@ -258,6 +266,7 @@ static void damon_test_merge_regions_of(struct kunit *test)
 		KUNIT_EXPECT_EQ(test, r->ar.end, eaddrs[i]);
 	}
 	damon_free_target(t);
+	damon_destroy_ctx(ctx);
 }
 
 static void damon_test_split_regions_of(struct kunit *test)
-- 
2.47.3

[RFC PATCH 08/16] mm/damon/core: disable access monitoring when probe weights are set

[SJ Park]

When users set probe weights, they are interested in the data
attributes.  Not necessarily they are interested in data access
patterns.  Disable the data access monitoring in the case.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 9bb884ab135ec..ad0f28469e633 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3714,17 +3714,18 @@ static int kdamond_fn(void *data)
 		unsigned long next_aggregation_sis = ctx->next_aggregation_sis;
 		unsigned long next_ops_update_sis = ctx->next_ops_update_sis;
 		unsigned long sample_interval = ctx->attrs.sample_interval;
+		bool access_check_disabled = damon_has_probe_weights(ctx);
 
 		if (kdamond_wait_activation(ctx))
 			break;
 
-		if (ctx->ops.prepare_access_checks)
+		if (!access_check_disabled && ctx->ops.prepare_access_checks)
 			ctx->ops.prepare_access_checks(ctx);
 
 		kdamond_usleep(sample_interval);
 		ctx->passed_sample_intervals++;
 
-		if (ctx->ops.check_accesses)
+		if (!access_check_disabled && ctx->ops.check_accesses)
 			max_nr_accesses = ctx->ops.check_accesses(ctx);
 		if (ctx->ops.apply_probes)
 			ctx->ops.apply_probes(ctx, false, false);
-- 
2.47.3

[RFC PATCH 09/16] mm/damon/core: set samples in apply_probes() if probe weights are set

[SJ Park]

When probe weights are set, the prepare_access_checks() ops callback is
not invoked, so sampling addresses of regions are unset.  Ask
apply_probes() to set those together in the case.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index ad0f28469e633..71008ee6ca243 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3728,7 +3728,8 @@ static int kdamond_fn(void *data)
 		if (!access_check_disabled && ctx->ops.check_accesses)
 			max_nr_accesses = ctx->ops.check_accesses(ctx);
 		if (ctx->ops.apply_probes)
-			ctx->ops.apply_probes(ctx, false, false);
+			ctx->ops.apply_probes(ctx, access_check_disabled,
+					false);
 
 		if (time_after_eq(ctx->passed_sample_intervals,
 					next_aggregation_sis)) {
-- 
2.47.3

[RFC PATCH 10/16] mm/damon/core: s/max_nr_accesses/max_merge_score/ in kdamond_fn()

[SJ Park]

When probe weights are set, DAMON merge logic works with the probe hits
weighted sum.  The core logic is setting the merge threshold based on
the access frequency, though.  Before using probe hits based threshold,
rename the variables to look more general.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 71008ee6ca243..a7ca69ea8e565 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3681,7 +3681,6 @@ static void kdamond_init_ctx(struct damon_ctx *ctx)
 static int kdamond_fn(void *data)
 {
 	struct damon_ctx *ctx = data;
-	unsigned int max_nr_accesses = 0;
 	unsigned long sz_limit = 0;
 
 	pr_debug("kdamond (%d) starts\n", current->pid);
@@ -3715,6 +3714,7 @@ static int kdamond_fn(void *data)
 		unsigned long next_ops_update_sis = ctx->next_ops_update_sis;
 		unsigned long sample_interval = ctx->attrs.sample_interval;
 		bool access_check_disabled = damon_has_probe_weights(ctx);
+		unsigned int max_merge_score = 0;
 
 		if (kdamond_wait_activation(ctx))
 			break;
@@ -3726,7 +3726,7 @@ static int kdamond_fn(void *data)
 		ctx->passed_sample_intervals++;
 
 		if (!access_check_disabled && ctx->ops.check_accesses)
-			max_nr_accesses = ctx->ops.check_accesses(ctx);
+			max_merge_score = ctx->ops.check_accesses(ctx);
 		if (ctx->ops.apply_probes)
 			ctx->ops.apply_probes(ctx, access_check_disabled,
 					false);
@@ -3734,7 +3734,7 @@ static int kdamond_fn(void *data)
 		if (time_after_eq(ctx->passed_sample_intervals,
 					next_aggregation_sis)) {
 			kdamond_merge_regions(ctx,
-					max_nr_accesses / 10,
+					max_merge_score / 10,
 					sz_limit);
 			/* online updates might be made */
 			sz_limit = damon_apply_min_nr_regions(ctx);
-- 
2.47.3

[RFC PATCH 11/16] mm/damon/core: get merge threshold from probe hits when weights are set

[SJ Park]

When probe weights are set, DAMON merges regions based on their probe
hits weighted sum.  But the merge threshold is calculated based on the
access frequency.  Update it to retrieve the maximum probe hits weighted
sum in the snapshot from apply_probes() ops callback, and generate the
threshold based on it.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index a7ca69ea8e565..83db073c74e2b 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3714,7 +3714,8 @@ static int kdamond_fn(void *data)
 		unsigned long next_ops_update_sis = ctx->next_ops_update_sis;
 		unsigned long sample_interval = ctx->attrs.sample_interval;
 		bool access_check_disabled = damon_has_probe_weights(ctx);
-		unsigned int max_merge_score = 0;
+		unsigned int max_merge_score = 0, max_wsum;
+		bool get_max_wsum;
 
 		if (kdamond_wait_activation(ctx))
 			break;
@@ -3727,9 +3728,18 @@ static int kdamond_fn(void *data)
 
 		if (!access_check_disabled && ctx->ops.check_accesses)
 			max_merge_score = ctx->ops.check_accesses(ctx);
-		if (ctx->ops.apply_probes)
-			ctx->ops.apply_probes(ctx, access_check_disabled,
-					false);
+		if (ctx->ops.apply_probes) {
+			if (time_after_eq(ctx->passed_sample_intervals,
+						next_aggregation_sis) &&
+					access_check_disabled)
+				get_max_wsum = true;
+			else
+				get_max_wsum = false;
+			max_wsum = ctx->ops.apply_probes(ctx,
+					access_check_disabled, get_max_wsum);
+			if (get_max_wsum)
+				max_merge_score = max_wsum;
+		}
 
 		if (time_after_eq(ctx->passed_sample_intervals,
 					next_aggregation_sis)) {
-- 
2.47.3

[RFC PATCH 12/16] mm/damon/core: implement damon_has_probe_weight()

[SJ Park]

DAMON monitors only data attributes when probe weights are set.
However, the function for detecting it is intentionally returning false
always.  The intention was to make changes for complete support of the
mode in a safe and incremental way.  Now all the building blocks are
made.  Complete the mode detection function so that the mode can really
start working.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 83db073c74e2b..b44393ccaf6b1 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -211,6 +211,12 @@ static struct damon_probe *damon_nth_probe(int n, struct damon_ctx *ctx)
 
 static bool damon_has_probe_weights(struct damon_ctx *c)
 {
+	struct damon_probe *p;
+
+	damon_for_each_probe(p, c) {
+		if (p->weight)
+			return true;
+	}
 	return false;
 }
 
-- 
2.47.3

[RFC PATCH 13/16] mm/damon/sysfs: implement probe/weight file

[SJ Park]

Implement a new sysfs file, 'weight', under probe directory.  Users will
be able to set the probe weight and enable the attributes only
monitoring using it.

Signed-off-by: SJ Park <sj@kernel.org>
---
 mm/damon/sysfs.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
index 6d7e36c9e509d..b5fe036f78015 100644
--- a/mm/damon/sysfs.c
+++ b/mm/damon/sysfs.c
@@ -1065,6 +1065,7 @@ static const struct kobj_type damon_sysfs_filters_ktype = {
 
 struct damon_sysfs_probe {
 	struct kobject kobj;
+	unsigned int weight;
 	struct damon_sysfs_filters *filters;
 };
 
@@ -1100,12 +1101,35 @@ static void damon_sysfs_probe_rm_dirs(struct damon_sysfs_probe *probe)
 	}
 }
 
+static ssize_t weight_show(struct kobject *kobj, struct kobj_attribute *attr,
+		char *buf)
+{
+	struct damon_sysfs_probe *probe = container_of(kobj,
+			struct damon_sysfs_probe, kobj);
+
+	return sysfs_emit(buf, "%u\n", probe->weight);
+}
+
+static ssize_t weight_store(struct kobject *kobj,
+		struct kobj_attribute *attr, const char *buf, size_t count)
+{
+	struct damon_sysfs_probe *probe = container_of(kobj,
+			struct damon_sysfs_probe, kobj);
+	int err = kstrtouint(buf, 0, &probe->weight);
+
+	return err ? err : count;
+}
+
 static void damon_sysfs_probe_release(struct kobject *kobj)
 {
 	kfree(container_of(kobj, struct damon_sysfs_probe, kobj));
 }
 
+static struct kobj_attribute damon_sysfs_probe_weight_attr =
+		__ATTR_RW_MODE(weight, 0600);
+
 static struct attribute *damon_sysfs_probe_attrs[] = {
+	&damon_sysfs_probe_weight_attr.attr,
 	NULL,
 };
 ATTRIBUTE_GROUPS(damon_sysfs_probe);
@@ -1965,6 +1989,7 @@ static int damon_sysfs_set_probes(struct damon_ctx *ctx,
 			return -ENOMEM;
 		damon_add_probe(ctx, p);
 		sys_probe = sys_probes->probes_arr[i];
+		p->weight = sys_probe->weight;
 		err = damon_sysfs_set_probe(p, sys_probe);
 		if (err)
 			return err;
-- 
2.47.3

[RFC PATCH 14/16] Docs/mm/damon/design: document attrs-only monitoring

[SJ Park]

Update DAMON design document for the attributes only monitoring mode.

Signed-off-by: SJ Park <sj@kernel.org>
---
 Documentation/mm/damon/design.rst | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 457d6e8bc7878..67398e2133036 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -316,6 +316,26 @@ Another way to do this for higher accuracy is using :ref:`DAMOS filter
 information in page level.  But, because it is operated in page level, the
 overhead is proportional to the size of the memory.
 
+Data Attributes-only Monitoring
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Data access is the primary monitoring information for DAMON.  Hence it
+:ref:`adjusts <damon_design_data_attrs_monitoring>` regions using the access
+:ref:`counter <damon_design_region_based_sampling>` (``nr_accesses``).  In some
+use cases, however, users may want some of :ref:`attributes
+<damon_design_data_attrs_monitoring>` to be the primary information.
+
+Data attributes-only monitoring mode supports this use case.  For the mode,
+each attribute probe has their priority weight value.  Users can describe by
+what combination of the attributes the primary information is deeecided, by
+setting the priority weight value.  If the total sum of the weights is not
+zero, the mode is enabled.  The regions adjustment mechaanism uses the weighted
+sum of the :ref:`probe hit counts <damon_design_data_attrs_monitoring>` instead
+of ``nr_accesses`` in the case.  When the mode is enabled, access monitoring is
+automatically turned off.  The access counter (``nr_accesses``) will always be
+zero and not updated.  Hence the mode is called Data Attributes "only"
+monitoring.
+
 Dynamic Target Space Updates Handling
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
2.47.3

[RFC PATCH 15/16] Docs/admin-guide/mm/damon/usage: document weight sysfs file

[SJ Park]

Update DAMON usage document for newly added probe weight file.

Signed-off-by: SJ Park <sj@kernel.org>
---
 Documentation/admin-guide/mm/damon/usage.rst | 11 ++++++++---
 Documentation/mm/damon/design.rst            |  5 +++++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index b2649ea011f93..4515088eba968 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -73,9 +73,10 @@ comma (",").
     │ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us
     │ │ │ │ │ │ nr_regions/min,max
     │ │ │ │ │ │ :ref:`probes <damon_usage_sysfs_probes>`/nr_probes
-    │ │ │ │ │ │ │ 0/filters/nr_filters
-    │ │ │ │ │ │ │ │ 0/type,matching,allow,path
-    │ │ │ │ │ │ │ │ ...
+    │ │ │ │ │ │ │ 0/weight
+    │ │ │ │ │ │ │ │ filters/nr_filters
+    │ │ │ │ │ │ │ │ │ 0/type,matching,allow,path
+    │ │ │ │ │ │ │ │ │ ...
     │ │ │ │ │ │ │ ...
     │ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
     │ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target,obsolete_target
@@ -286,6 +287,10 @@ In each probe directory, one directory, ``filters`` exists.  The directory
 contains files for installing filters for the probe, that is used to determine
 the data attribute for the probe.
 
+Each probe directory also contains ``weight`` file.  Reading from and writing
+to the file gets and sets the :ref:`atttributes-only monitoring
+<damon_design_attrs_only_monitoring>` weight for the attribute of the probe.
+
 In the beginning, ``filters`` directory has only one file, ``nr_filters``.
 Writing a number (``N``) to the file creates the number of child directories
 named ``0`` to ``N-1``.  Each directory represents each filter and works in a
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 67398e2133036..129acb1da4e19 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -316,6 +316,8 @@ Another way to do this for higher accuracy is using :ref:`DAMOS filter
 information in page level.  But, because it is operated in page level, the
 overhead is proportional to the size of the memory.
 
+.. _damon_design_attrs_only_monitoring:
+
 Data Attributes-only Monitoring
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -336,6 +338,9 @@ automatically turned off.  The access counter (``nr_accesses``) will always be
 zero and not updated.  Hence the mode is called Data Attributes "only"
 monitoring.
 
+Refer to the :ref:`admin guide <damon_usage_sysfs_probes>` to know how users
+can use the mode.
+
 Dynamic Target Space Updates Handling
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
2.47.3

[RFC PATCH 16/16] Docs/ABI/damon: document probe weight file

[SJ Park]

Update DAMON ABI document for the newly added probe weight sysfs file.

Signed-off-by: SJ Park <sj@kernel.org>
---
 Documentation/ABI/testing/sysfs-kernel-mm-damon | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index dd6b5bd76e119..907a504fb64c5 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -164,6 +164,12 @@ Description:	Writing a number 'N' to this file creates the number of
 		directories for each DAMON probe named '0' to 'N-1' under the
 		probes/ directory.
 
+What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/probes/<P>/weight
+Date:		Jul 2026
+Contact:	SJ Park <sj@kernel.org>
+Description:	Writing to and reading from this file sets and gets the
+		per-probe attribute weight.
+
 What:		/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/probes/<P>/filters/nr_filters
 Date:		May 2026
 Contact:	SJ Park <sj@kernel.org>
-- 
2.47.3

Re: [RFC PATCH 01/16] mm/damon/core: introduce damon_probe->weight

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing kernel-doc description for the new `weight` field in `struct damon_probe`.
--

commit 4be82423c8a2e9beb3264e298ab3af6bd580eea9
Author: SJ Park <sj@kernel.org>

mm/damon/core: introduce damon_probe->weight

This commit adds a new weight field to the damon_probe structure. The field
is used to specify the degree of the API caller's interest in the data
attribute of the probe.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 616bdf0954b52..257a4769296ab 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -763,6 +763,7 @@ struct damon_filter {
>   * @list:	Siblings list.
>   */
>  struct damon_probe {
> +	unsigned int weight;

[Severity: Low]
Should the kernel-doc comment block above struct damon_probe be updated to
include a description for the new weight field? Without it, running
scripts/kernel-doc might emit a warning about the undocumented field.

>  	struct list_head filters;
>  	struct list_head list;
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=1

Re: [RFC PATCH 14/16] Docs/mm/damon/design: document attrs-only monitoring

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Spelling mistakes in the newly added documentation: 'deeecided' and 'mechaanism'.
--

commit 802f6df741c5d3bfcb1ed21eadbf33ebee4db496
Author: SJ Park <sj@kernel.org>

Docs/mm/damon/design: document attrs-only monitoring

This commit updates the DAMON design document to include a section
describing the data attributes-only monitoring mode.

> diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
> index 457d6e8bc7878..67398e2133036 100644
> --- a/Documentation/mm/damon/design.rst
> +++ b/Documentation/mm/damon/design.rst

[ ... ]

> @@ -316,6 +316,26 @@ Another way to do this for higher accuracy is using :ref:`DAMOS filter
>  information in page level.  But, because it is operated in page level, the
>  overhead is proportional to the size of the memory.
>  
> +Data Attributes-only Monitoring
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Data access is the primary monitoring information for DAMON.  Hence it
> +:ref:`adjusts <damon_design_data_attrs_monitoring>` regions using the access
> +:ref:`counter <damon_design_region_based_sampling>` (``nr_accesses``).  In some
> +use cases, however, users may want some of :ref:`attributes
> +<damon_design_data_attrs_monitoring>` to be the primary information.
> +
> +Data attributes-only monitoring mode supports this use case.  For the mode,
> +each attribute probe has their priority weight value.  Users can describe by
> +what combination of the attributes the primary information is deeecided, by

[Severity: Low]
This isn't a bug, but there is a typo here: "deeecided" should be "decided".

> +setting the priority weight value.  If the total sum of the weights is not
> +zero, the mode is enabled.  The regions adjustment mechaanism uses the weighted

[Severity: Low]
This isn't a bug, but there is another typo here: "mechaanism" should be
"mechanism".

> +sum of the :ref:`probe hit counts <damon_design_data_attrs_monitoring>` instead
> +of ``nr_accesses`` in the case.  When the mode is enabled, access monitoring is
> +automatically turned off.  The access counter (``nr_accesses``) will always be
> +zero and not updated.  Hence the mode is called Data Attributes "only"
> +monitoring.
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=14

Re: [RFC PATCH 15/16] Docs/admin-guide/mm/damon/usage: document weight sysfs file

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Misspelled word 'atttributes' with three 't's in the added documentation.
--

commit 0678cc4de62904aa4e60ad181dd2e6c07336bf2d
Author: SJ Park <sj@kernel.org>

Docs/admin-guide/mm/damon/usage: document weight sysfs file

This commit updates the DAMON usage document to include the newly added
probe weight file.

> diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
> index b2649ea011f93..4515088eba968 100644
> --- a/Documentation/admin-guide/mm/damon/usage.rst
> +++ b/Documentation/admin-guide/mm/damon/usage.rst

[ ... ]

> @@ -286,6 +287,10 @@ In each probe directory, one directory, ``filters`` exists.  The directory
>  contains files for installing filters for the probe, that is used to determine
>  the data attribute for the probe.
>  
> +Each probe directory also contains ``weight`` file.  Reading from and writing
> +to the file gets and sets the :ref:`atttributes-only monitoring

[Severity: Low]
This isn't a bug, but there is a typo here. The word attributes is misspelled
with three ts.

> +<damon_design_attrs_only_monitoring>` weight for the attribute of the probe.
> +
>  In the beginning, ``filters`` directory has only one file, ``nr_filters``.
>  Writing a number (``N``) to the file creates the number of child directories

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=15

Re: [RFC PATCH 02/16] mm/damon/core: ask apply_probes() ops callback to set sampling address

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Malformed kernel-doc syntax and typos in the `apply_probes` documentation.
--

commit 2691e8480612ea2e98837a8db1eb30da170cf383
Author: SJ Park <sj@kernel.org>

mm/damon/core: ask apply_probes() ops callback to set sampling address

This patch updates the apply_probes() callback in struct damon_operations
by adding a set_samples argument. It allows apply_probes() to directly set
the sampling address for each region, minimizing unnecessary iterations.

> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 257a4769296ab..7c82cd0c2f29d 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -646,7 +646,8 @@ enum damon_ops_id {
>   * It should also return max number of observed accesses that made as a result
>   * of its update.  The value will be used for regions adjustment threshold.
>   * @apply_probes should apply the data attribute probes to each region and
> - * accordingly update the probe hits counter of the region.
> + * accordingly update the probe hits counter of the region.  It should also
> + * &set sampling_addr or each region if &set_samples is true.

[Severity: Low]
This isn't a bug, but there appear to be a few typos and kernel-doc syntax
issues in this documentation update.

Did you mean "for each" instead of "or each"?

Additionally, parameter references in kernel-doc typically use @set_samples
rather than &set_samples, and the &set prefix seems unintended here.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=2

Re: [RFC PATCH 07/16] mm/damon/core: extend merge function to work with probe hits

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Incompatible scale and domain mismatch between weighted scores and unweighted merge thresholds.
- [High] Unsafe use of `abs()` macro on large unsigned integer score differences causes silent signed integer overflow.
- [Medium] Calculating the weighted sum of probe hits in `damon_probe_hits_wsum` can easily overflow a 32-bit `unsigned int`.

Pre-existing issues:
- [High] Weighted average calculations in `damon_merge_two_regions` silently overflow 32-bit `unsigned long` on 32-bit architectures.
--

commit 54d6e0bb9900e63a1a016ffee9632b6aa602175b
Author: SJ Park <sj@kernel.org>

mm/damon/core: extend merge function to work with probe hits

This commit extends damon_merge_regions_of() to consider the weighted sum
of probe hits when calculating regions to merge, introducing
damon_has_probe_weights() and modifying the scoring logic to use these weights.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index c370eaff5795d..f6e03746b170e 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -3187,6 +3192,16 @@ static void damon_merge_two_regions(struct damon_target *t,
>  	damon_destroy_region(r, t);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but can the weighted average
calculations in damon_merge_two_regions() silently overflow a 32-bit
unsigned long on 32-bit architectures?

On 32-bit architectures, sz_l is a 32-bit unsigned long.

If the region size is large (e.g., hundreds of megabytes), multiplying sz_l
by nr_accesses or probe_hits could exceed the 4.29B maximum of a 32-bit
integer, corrupting the merged region's statistics.

mm/damon/core.c:damon_merge_two_regions() {
...
	l->nr_accesses = (l->nr_accesses * sz_l + r->nr_accesses * sz_r) /
			(sz_l + sz_r);
...
	for (i = 0; i < DAMON_MAX_PROBES; i++)
		l->probe_hits[i] = (l->probe_hits[i] * sz_l + r->probe_hits[i]
				* sz_r) / (sz_l + sz_r);
...
}

> +static unsigned int damon_merge_score(struct damon_region *r, bool last,
> +		struct damon_ctx *ctx, bool use_probe_hits)
> +{
> +	if (use_probe_hits)
> +		return damon_probe_hits_wsum(r, last, ctx);

[Severity: Medium]
Can the multiplication in damon_probe_hits_wsum() overflow a 32-bit
unsigned int?

probe->weight is an unsigned int.

If users supply a large weight, multiplying it by r->probe_hits[i] (which can
be up to 255) might exceed UINT_MAX, causing the sum to wrap around and yield
artificially small scores for highly active regions.

mm/damon/core.c:damon_probe_hits_wsum() {
...
		if (last)
			sum += r->last_probe_hits[i++] * probe->weight;
		else
			sum += r->probe_hits[i++] * probe->weight;
...
}

> +	if (last)
> +		return r->last_nr_accesses;
> +	return r->nr_accesses;
> +}
> +
>  /*
>   * Merge adjacent regions having similar access frequencies
>   *
> @@ -3195,24 +3210,37 @@ static void damon_merge_two_regions(struct damon_target *t,
>   * sz_limit	size upper limit of each region
>   */
>  static void damon_merge_regions_of(struct damon_target *t, unsigned int thres,
> -				   unsigned long sz_limit)
> +		unsigned long sz_limit, struct damon_ctx *ctx)
>  {
>  	struct damon_region *r, *prev = NULL, *next;
> +	bool use_probe_hits = damon_has_probe_weights(ctx);
>  
>  	damon_for_each_region_safe(r, next, t) {
> -		if (abs(r->nr_accesses - r->last_nr_accesses) > thres)
> +		unsigned int score, last_score;
> +
> +		score = damon_merge_score(r, false, ctx, use_probe_hits);
> +		last_score = damon_merge_score(r, true, ctx, use_probe_hits);
> +
> +		if (abs(score - last_score) > thres)

[Severity: High]
Does the use of abs() here cause a silent signed integer overflow for large
unsigned differences?

The macro abs() implicitly casts an unsigned int to a signed int.

If the mathematical difference between score and last_score exceeds INT_MAX
(which might happen with large user-defined probe weights), the cast wraps to
a negative number.

The abs() macro then negates it into an artificially small positive integer,
which could cause the code to incorrectly bypass the > thres check and merge
regions with vastly different access profiles.

[Severity: High]
Is there a domain mismatch between the weighted score differences and the
unweighted thres parameter?

When use_probe_hits is true, the score is a weighted sum derived from probe
hits and user-defined weights. However, thres operates in the unweighted access
frequency domain.

This mismatch appears to carry over to kdamond_merge_regions(), where max_thres
is also scaled in the unweighted domain (aggr_interval / sample_interval).

Because weighted scores operate in a different numerical domain, could they
easily exceed max_thres, forcing the merge loop in kdamond_merge_regions() to
terminate prematurely?

mm/damon/core.c:kdamond_merge_regions() {
...
	max_thres = c->attrs.aggr_interval /
		(c->attrs.sample_interval ?  c->attrs.sample_interval : 1);
	do {
...
		threshold = max(1, threshold * 2);
	} while (nr_regions > c->attrs.max_nr_regions &&
			threshold / 2 < max_thres);
...
}

>  			r->age = 0;
> -		else if ((r->nr_accesses == 0) != (r->last_nr_accesses == 0))
> +		else if ((score == 0) != (last_score == 0))
>  			r->age = 0;
>  		else
>  			r->age++;
>  
> -		if (prev && prev->ar.end == r->ar.start &&
> -		    abs(prev->nr_accesses - r->nr_accesses) <= thres &&
> -		    damon_sz_region(prev) + damon_sz_region(r) <= sz_limit)
> -			damon_merge_two_regions(t, prev, r);
> -		else
> -			prev = r;
> +		if (!prev)
> +			goto set_prev_continue;
> +		if (prev->ar.end != r->ar.start)
> +			goto set_prev_continue;
> +		if (abs(damon_merge_score(prev, false, ctx, use_probe_hits) -
> +					score) > thres)

[Severity: High]
Does this abs() usage also suffer from the same silent signed integer overflow
as mentioned above when comparing large unsigned score differences?

> +			goto set_prev_continue;
> +		if (damon_sz_region(prev) + damon_sz_region(r) > sz_limit)
> +			goto set_prev_continue;
> +		damon_merge_two_regions(t, prev, r);
> +		continue;
> +set_prev_continue:
> +		prev = r;
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=7

Re: [RFC PATCH 03/16] mm/damon/paddr: set samples in apply_probes() if requested

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The `probe_hits` counter in `struct damon_region` is an 8-bit integer (`unsigned char`), which overflows if the ratio of aggregation interval to sampling interval exceeds 255. When this wrapped value is used by `damon_merge_score()` (introduced in this series via `damon_probe_hits_wsum()`), DAMON incorrectly merges regions, breaking its core tracking logic.
--

commit 26a2b31429c08214403a84c01f1b8d381e461d92
Author: SJ Park <sj@kernel.org>

mm/damon/paddr: set samples in apply_probes() if requested

The apply_probe() callback implementation in DAMON_PADDR ignores the
set_samples parameter. This commit updates it to respect the parameter by
setting the sampling address if requested.

> diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> index b13bf7c6eade3..ff4fcca949660 100644
> --- a/mm/damon/paddr.c
> +++ b/mm/damon/paddr.c
> @@ -178,6 +178,10 @@ static void damon_pa_apply_probes(struct damon_ctx *ctx, bool set_samples)
>  			phys_addr_t pa;
>  			struct folio *folio;
>  
> +			if (set_samples)
> +				r->sampling_addr = damon_rand(ctx, r->ar.start,
> +						r->ar.end);
> +
>  			pa = damon_pa_phys_addr(r->sampling_addr,
>  					ctx->addr_unit);
>  			folio = damon_get_folio(PHYS_PFN(pa));

[Severity: High]
This is a pre-existing issue, but does this code overflow probe_hits[]?

Looking at include/linux/damon.h, probe_hits is defined as an 8-bit integer:

struct damon_region {
    ...
    unsigned char probe_hits[DAMON_MAX_PROBES];

Shortly after the sampling address is set in damon_pa_apply_probes(), this
counter is incremented:

    damon_for_each_probe(p, ctx) {
        if (damon_pa_filter_pass(pa, folio, p))
            r->probe_hits[i]++;

If a user configures DAMON such that the ratio of aggregation interval to
sampling interval exceeds 255, this counter will overflow and wrap around to
zero.

Since this patch series modifies damon_merge_score() in mm/damon/core.c to
rely on this counter:

    if (use_probe_hits)
        return damon_probe_hits_wsum(r, last, ctx);

Could this overflow cause highly-accessed regions to be treated as having few
matches, leading to incorrect region merging and breaking DAMON's core tracking
logic for filters?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=3

Re: [RFC PATCH 11/16] mm/damon/core: get merge threshold from probe hits when weights are set

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The merge threshold limit (`max_thres`) in `kdamond_merge_regions` is not scaled for probe weights, causing premature termination of the region merging loop and failing to enforce the user-defined `max_nr_regions` limit.

Pre-existing issues:
- [High] When probe weights are configured for operations that do not implement `apply_probes` (e.g., `vaddr`), the merge threshold becomes 0 and regions are improperly and aggressively merged.
--

commit 23bf451408faae1b0a1f1eb841dc6f4b60077861
Author: SJ Park <sj@kernel.org>
Subject: mm/damon/core: get merge threshold from probe hits when weights are set

When probe weights are set, DAMON merges regions based on their probe hits
weighted sum, but the merge threshold is calculated based on access frequency.
Update it to retrieve the maximum probe hits weighted sum in the snapshot from
the apply_probes() ops callback, and generate the threshold based on it.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index bd6d836f1db5e..7a070cfb7cd1b 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3683,9 +3684,18 @@ static int kdamond_fn(void *data)
>  
>  		if (!access_check_disabled && ctx->ops.check_accesses)
>  			max_merge_score = ctx->ops.check_accesses(ctx);
> -		if (ctx->ops.apply_probes)
> -			ctx->ops.apply_probes(ctx, access_check_disabled,
> -					false);
> +		if (ctx->ops.apply_probes) {
> +			if (time_after_eq(ctx->passed_sample_intervals,
> +						next_aggregation_sis) &&
> +					access_check_disabled)
> +				get_max_wsum = true;
> +			else
> +				get_max_wsum = false;
> +			max_wsum = ctx->ops.apply_probes(ctx,
> +					access_check_disabled, get_max_wsum);
> +			if (get_max_wsum)
> +				max_merge_score = max_wsum;
> +		}

[Severity: High]
This is a pre-existing issue, but what happens if a user configures probe
weights for operations that do not implement apply_probes (like vaddr)?

When damon_has_probe_weights() returns true, access checks are disabled. If
the operations lack an apply_probes callback, max_merge_score will remain 0.

Will this cause all regions to be improperly and unconditionally merged into
maximum-sized chunks, resulting in a loss of monitoring resolution?

[Severity: High]
Does kdamond_merge_regions() properly handle this new weight-based score limit?

Just after this block, max_merge_score is passed into kdamond_merge_regions():

mm/damon/core.c:kdamond_fn() {
    ...
		if (time_after_eq(ctx->passed_sample_intervals,
					next_aggregation_sis)) {
			kdamond_merge_regions(ctx,
					max_merge_score / 10,
					sz_limit);
    ...
}

Because max_thres inside kdamond_merge_regions() is hardcoded to the maximum
possible frequency of unweighted accesses, rather than dynamically accounting
for probe weights, the scaling loop termination condition:

mm/damon/core.c:kdamond_merge_regions() {
	...
	} while (nr_regions > c->attrs.max_nr_regions &&
			threshold / 2 < max_thres);
	...
}

appears to instantly fail when the initial threshold is already large due to
probe weights.

Will this cause an early abort of the fallback loop, leaving regions unmerged
and failing to enforce the max_nr_regions limit?

>  
>  		if (time_after_eq(ctx->passed_sample_intervals,
>  					next_aggregation_sis)) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=11

Re: [RFC PATCH 05/16] mm/damon/core: implement damon_probe_hits_wsum()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The calculation of the weighted sum in `damon_probe_hits_wsum()` can overflow the 32-bit `unsigned int` datatype.
--

commit fa25d0914791f2e39d32d91b9baaf69eaeb0a208
Author: SJ Park <sj@kernel.org>

mm/damon/core: implement damon_probe_hits_wsum()

This commit introduces a new function damon_probe_hits_wsum() to calculate
the weighted sum of probe hits for a given region. This weighted sum is
intended to be used by both users and internal DAMON logic like region
merging.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index ec6b099bd8790..c370eaff5795d 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -390,6 +390,30 @@ static bool damon_is_last_region(struct damon_region *r,
>  	return list_is_last(&r->list, &t->regions_list);
>  }
>  
> +/**
> + * damon_probe_hits_wsum() - Returns probe hits weighted sum of a region.
> + * @r:		region to get the weigted sum of.
> + * @last:	if the request is for last-window agggregated probe hits.
> + * @ctx:	context of &r.
> + *
> + * Return: the weighted sum of probe hits of the region.
> + */
> +unsigned int damon_probe_hits_wsum(struct damon_region *r, bool last,
> +		struct damon_ctx *ctx)
> +{
> +	struct damon_probe *probe;
> +	unsigned int sum = 0;
> +	int i = 0;
> +
> +	damon_for_each_probe(probe, ctx) {
> +		if (last)
> +			sum += r->last_probe_hits[i++] * probe->weight;
> +		else
> +			sum += r->probe_hits[i++] * probe->weight;

[Severity: Medium]
Can this calculation overflow the 32-bit unsigned integer?

Since sum and probe->weight are both typed as unsigned int, if a
sufficiently large probe weight (for example, larger than 16,843,000) is
configured via sysfs, this multiplication and accumulation might wrap around.

If the score wraps around to an artificially low value, would this cause
DAMON's region merging logic to behave incorrectly due to unexpected
thresholds?

> +	}
> +	return sum;
> +}
> +
>  /*
>   * Check whether a region is intersecting an address range
>   *

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=5

Re: [RFC PATCH 12/16] mm/damon/core: implement damon_has_probe_weight()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] `damon_has_probe_weights()` returns `true` even for DAMON contexts that do not implement the `apply_probes` operation callback (e.g., `vaddr` and `fvaddr`), causing DAMON to silently bypass access checks and completely stop monitoring memory.

Pre-existing issues:
- [High] Integer overflow in `abs()` macro usage with large unsigned probe scores breaks DAMON region merging.
- [High] Multiplication overflow in `damon_merge_two_regions` when calculating merged probe hits and access counts on 32-bit systems.
--

commit 4b421534e3283ef89ac2afef3f02956b0510da1e
Author: SJ Park <sj@kernel.org>

mm/damon/core: implement damon_has_probe_weight()
    
DAMON monitors only data attributes when probe weights are set. However,
the function for detecting it is intentionally returning false always.
Now all the building blocks are made. Complete the mode detection function
so that the mode can really start working.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7a070cfb7cd1b..c7de55865b9c9 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -211,6 +211,12 @@ static struct damon_probe *damon_nth_probe(int n, struct damon_ctx *ctx)
>  
>  static bool damon_has_probe_weights(struct damon_ctx *c)
>  {
> +	struct damon_probe *p;
> +
> +	damon_for_each_probe(p, c) {
> +		if (p->weight)
> +			return true;
> +	}

[Severity: High]
Does this code need to check if the underlying ops struct supports probes?

If a context like vaddr or fvaddr has a probe weight configured via sysfs,
this will return true. This causes access_check_disabled to be set to true in
kdamond_fn(), which skips check_accesses():

mm/damon/core.c:kdamond_fn() {
    ...
    bool access_check_disabled = damon_has_probe_weights(ctx);
    ...
}

Because ctx->ops.apply_probes is NULL for vaddr, the apply block is then
skipped and max_merge_score remains 0, which causes kdamond_merge_regions()
to aggressively merge everything with a threshold of 0.

>  	return false;
>  }

I also noticed a couple of pre-existing issues in this file:

[Severity: High]
This is a pre-existing issue, but does this code overflow the 32-bit
boundary on 32-bit systems?

mm/damon/core.c:damon_merge_two_regions() {
[ ... ]
	l->nr_accesses = (l->nr_accesses * sz_l + r->nr_accesses * sz_r) /
			(sz_l + sz_r);
[ ... ]
	for (i = 0; i < DAMON_MAX_PROBES; i++)
		l->probe_hits[i] = (l->probe_hits[i] * sz_l + r->probe_hits[i]
				* sz_r) / (sz_l + sz_r);
[ ... ]
}

If a region size reaches around 42MB on a 32-bit architecture and
nr_accesses is around 100, the multiplication nr_accesses * sz_l could
exceed 4.2 billion and silently overflow the 32-bit unsigned long,
corrupting the memory access statistics for merged regions.

[Severity: High]
This is a pre-existing issue, but can the absolute difference of two large
unsigned integers be evaluated incorrectly here?

mm/damon/core.c:damon_merge_regions_of() {
[ ... ]
		score = damon_merge_score(r, false, ctx, use_probe_hits);
		last_score = damon_merge_score(r, true, ctx, use_probe_hits);

		if (abs(score - last_score) > thres)
			r->age = 0;
[ ... ]
}

If a user configures a large probe weight via sysfs such that the weighted
sum exceeds INT_MAX, score - last_score produces a large unsigned int. The
abs() macro explicitly casts unsigned types to signed types, which would
wrap into a negative signed integer and then be negated into a much smaller
positive value. This could bypass the greater than threshold check and
prevent regions from resetting their age.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=12

Re: [RFC PATCH 08/16] mm/damon/core: disable access monitoring when probe weights are set

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] kdamond_merge_regions loop terminates prematurely because max_thres is capped by access count limit, breaking the scaling of threshold for probe hits.
- [High] Silent breakage of vaddr/fvaddr monitoring when probe weights are configured via sysfs.

Pre-existing issues:
- [High] Unbounded integer overflow of probe_hits array elements in struct damon_region.
--

commit 6a6c230b9f6562af956ffa250fd34b615f031ce5
Author: SJ Park <sj@kernel.org>

mm/damon/core: disable access monitoring when probe weights are set
    
When users set probe weights, they are interested in the data
attributes.  Not necessarily they are interested in data access
patterns.  Disable the data access monitoring in the case.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index f6e03746b170e..db4e404f95bd1 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3670,17 +3670,18 @@ static int kdamond_fn(void *data)
>  		unsigned long next_aggregation_sis = ctx->next_aggregation_sis;
>  		unsigned long next_ops_update_sis = ctx->next_ops_update_sis;
>  		unsigned long sample_interval = ctx->attrs.sample_interval;
> +		bool access_check_disabled = damon_has_probe_weights(ctx);
>  
>  		if (kdamond_wait_activation(ctx))
>  			break;
>  
> -		if (ctx->ops.prepare_access_checks)
> +		if (!access_check_disabled && ctx->ops.prepare_access_checks)
>  			ctx->ops.prepare_access_checks(ctx);
>  
>  		kdamond_usleep(sample_interval);
>  		ctx->passed_sample_intervals++;
>  
> -		if (ctx->ops.check_accesses)
> +		if (!access_check_disabled && ctx->ops.check_accesses)
>  			max_nr_accesses = ctx->ops.check_accesses(ctx);

[Severity: High]
If a user configures a DAMON context with vaddr or fvaddr operations,
and creates a probe via sysfs with a weight, will this bypass check_accesses
without a fallback?

It appears that damon_has_probe_weights() will return true and
access_check_disabled will become true.

This unconditionally bypasses ctx->ops.check_accesses(ctx).

However, if vaddr and fvaddr operations do not currently implement
apply_probes (leaving it NULL), it seems no sampling will occur at all.

Does this silently leave the context without any functional monitoring for
virtual address spaces?

>  		if (ctx->ops.apply_probes)
>  			ctx->ops.apply_probes(ctx, false, false);

[Severity: High]
Could this change cause the loop in kdamond_merge_regions() to exit
prematurely when using probe weights?

When probe weights are enabled, kdamond_merge_regions() starts its
region merging loop with an initial threshold scaled by the maximum
probe hit weighted sum.

However, the loop's upper bound cap, max_thres, remains capped by the
maximum possible access counts:

mm/damon/core.c:kdamond_merge_regions() {
    ...
    } while (nr_regions > c->attrs.max_nr_regions &&
             threshold / 2 < max_thres);
}

Because a probe hit weighted sum can easily exceed the access-based max_thres
by orders of magnitude, the loop condition can fail on the very first
iteration.

Will this force the loop to exit prematurely without adequately
doubling the threshold, leaving nr_regions exceeding max_nr_regions?


[Severity: High]
This isn't a bug introduced by this patch, but there is an unbounded
integer overflow of the probe_hits array elements in struct damon_region.

Running DAMON with a large aggregation interval relative to the sample
interval can cause the unsigned char probe_hits counter to wrap around.

In damon_pa_apply_probes(), the counter is incremented without bounds
checking:

mm/damon/paddr.c:damon_pa_apply_probes() {
    ...
    if (damon_pa_filter_pass(pa, folio, p))
        r->probe_hits[i]++;
    ...
}

Since probe_hits is defined as an unsigned char (max 255) in
struct damon_region:

include/linux/damon.h {
    ...
    unsigned char probe_hits[DAMON_MAX_PROBES];
    ...
}

If a region satisfies a probe for more than 255 sampling intervals within
a single aggregation window, the counter will wrap around to 0 multiple
times.

Might this feed arbitrary garbage values to damon_probe_hits_wsum(),
corrupting the metric that region merging and scheme application rely on?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=8

Re: [RFC PATCH 01/16] mm/damon/core: introduce damon_probe->weight

[SJ Park]

On Sun, 05 Jul 2026 21:04:53 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Missing kernel-doc description for the new `weight` field in `struct damon_probe`.
> --
> 
> commit 4be82423c8a2e9beb3264e298ab3af6bd580eea9
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: introduce damon_probe->weight
> 
> This commit adds a new weight field to the damon_probe structure. The field
> is used to specify the degree of the API caller's interest in the data
> attribute of the probe.
> 
> > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > index 616bdf0954b52..257a4769296ab 100644
> > --- a/include/linux/damon.h
> > +++ b/include/linux/damon.h
> > @@ -763,6 +763,7 @@ struct damon_filter {
> >   * @list:	Siblings list.
> >   */
> >  struct damon_probe {
> > +	unsigned int weight;
> 
> [Severity: Low]
> Should the kernel-doc comment block above struct damon_probe be updated to
> include a description for the new weight field? Without it, running
> scripts/kernel-doc might emit a warning about the undocumented field.

Good catch.  I will add the comment on the next revision.

> 
> >  	struct list_head filters;
> >  	struct list_head list;
> >  };
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=1


Thanks,
SJ

Re: [RFC PATCH 02/16] mm/damon/core: ask apply_probes() ops callback to set sampling address

[SJ Park]

On Sun, 05 Jul 2026 21:07:37 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Malformed kernel-doc syntax and typos in the `apply_probes` documentation.
> --
> 
> commit 2691e8480612ea2e98837a8db1eb30da170cf383
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: ask apply_probes() ops callback to set sampling address
> 
> This patch updates the apply_probes() callback in struct damon_operations
> by adding a set_samples argument. It allows apply_probes() to directly set
> the sampling address for each region, minimizing unnecessary iterations.
> 
> > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > index 257a4769296ab..7c82cd0c2f29d 100644
> > --- a/include/linux/damon.h
> > +++ b/include/linux/damon.h
> > @@ -646,7 +646,8 @@ enum damon_ops_id {
> >   * It should also return max number of observed accesses that made as a result
> >   * of its update.  The value will be used for regions adjustment threshold.
> >   * @apply_probes should apply the data attribute probes to each region and
> > - * accordingly update the probe hits counter of the region.
> > + * accordingly update the probe hits counter of the region.  It should also
> > + * &set sampling_addr or each region if &set_samples is true.
> 
> [Severity: Low]
> This isn't a bug, but there appear to be a few typos and kernel-doc syntax
> issues in this documentation update.
> 
> Did you mean "for each" instead of "or each"?
> 
> Additionally, parameter references in kernel-doc typically use @set_samples
> rather than &set_samples, and the &set prefix seems unintended here.

Nice catches.  I will fix those in the next revision.

> 
> [ ... ]
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=2


Thanks,
SJ

Re: [RFC PATCH 03/16] mm/damon/paddr: set samples in apply_probes() if requested

[SJ Park]

On Sun, 05 Jul 2026 21:11:47 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The `probe_hits` counter in `struct damon_region` is an 8-bit integer (`unsigned char`), which overflows if the ratio of aggregation interval to sampling interval exceeds 255. When this wrapped value is used by `damon_merge_score()` (introduced in this series via `damon_probe_hits_wsum()`), DAMON incorrectly merges regions, breaking its core tracking logic.
> --
> 
> commit 26a2b31429c08214403a84c01f1b8d381e461d92
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/paddr: set samples in apply_probes() if requested
> 
> The apply_probe() callback implementation in DAMON_PADDR ignores the
> set_samples parameter. This commit updates it to respect the parameter by
> setting the sampling address if requested.
> 
> > diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> > index b13bf7c6eade3..ff4fcca949660 100644
> > --- a/mm/damon/paddr.c
> > +++ b/mm/damon/paddr.c
> > @@ -178,6 +178,10 @@ static void damon_pa_apply_probes(struct damon_ctx *ctx, bool set_samples)
> >  			phys_addr_t pa;
> >  			struct folio *folio;
> >  
> > +			if (set_samples)
> > +				r->sampling_addr = damon_rand(ctx, r->ar.start,
> > +						r->ar.end);
> > +
> >  			pa = damon_pa_phys_addr(r->sampling_addr,
> >  					ctx->addr_unit);
> >  			folio = damon_get_folio(PHYS_PFN(pa));
> 
> [Severity: High]
> This is a pre-existing issue, but does this code overflow probe_hits[]?
> 
> Looking at include/linux/damon.h, probe_hits is defined as an 8-bit integer:
> 
> struct damon_region {
>     ...
>     unsigned char probe_hits[DAMON_MAX_PROBES];
> 
> Shortly after the sampling address is set in damon_pa_apply_probes(), this
> counter is incremented:
> 
>     damon_for_each_probe(p, ctx) {
>         if (damon_pa_filter_pass(pa, folio, p))
>             r->probe_hits[i]++;
> 
> If a user configures DAMON such that the ratio of aggregation interval to
> sampling interval exceeds 255, this counter will overflow and wrap around to
> zero.
> 
> Since this patch series modifies damon_merge_score() in mm/damon/core.c to
> rely on this counter:
> 
>     if (use_probe_hits)
>         return damon_probe_hits_wsum(r, last, ctx);
> 
> Could this overflow cause highly-accessed regions to be treated as having few
> matches, leading to incorrect region merging and breaking DAMON's core tracking
> logic for filters?

It can overflow, and it is the intended behavior.

Since the core layer parameters validation series is just merged into mm-new,
I'm considering limiting aggregation interval to be less than 256 * sampling
interval using the validation mechanism, though.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=3


Thanks,
SJ

Re: [RFC PATCH 05/16] mm/damon/core: implement damon_probe_hits_wsum()

[SJ Park]

On Sun, 05 Jul 2026 21:13:50 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The calculation of the weighted sum in `damon_probe_hits_wsum()` can overflow the 32-bit `unsigned int` datatype.
> --
> 
> commit fa25d0914791f2e39d32d91b9baaf69eaeb0a208
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: implement damon_probe_hits_wsum()
> 
> This commit introduces a new function damon_probe_hits_wsum() to calculate
> the weighted sum of probe hits for a given region. This weighted sum is
> intended to be used by both users and internal DAMON logic like region
> merging.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index ec6b099bd8790..c370eaff5795d 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > @@ -390,6 +390,30 @@ static bool damon_is_last_region(struct damon_region *r,
> >  	return list_is_last(&r->list, &t->regions_list);
> >  }
> >  
> > +/**
> > + * damon_probe_hits_wsum() - Returns probe hits weighted sum of a region.
> > + * @r:		region to get the weigted sum of.
> > + * @last:	if the request is for last-window agggregated probe hits.
> > + * @ctx:	context of &r.
> > + *
> > + * Return: the weighted sum of probe hits of the region.
> > + */
> > +unsigned int damon_probe_hits_wsum(struct damon_region *r, bool last,
> > +		struct damon_ctx *ctx)
> > +{
> > +	struct damon_probe *probe;
> > +	unsigned int sum = 0;
> > +	int i = 0;
> > +
> > +	damon_for_each_probe(probe, ctx) {
> > +		if (last)
> > +			sum += r->last_probe_hits[i++] * probe->weight;
> > +		else
> > +			sum += r->probe_hits[i++] * probe->weight;
> 
> [Severity: Medium]
> Can this calculation overflow the 32-bit unsigned integer?
> 
> Since sum and probe->weight are both typed as unsigned int, if a
> sufficiently large probe weight (for example, larger than 16,843,000) is
> configured via sysfs, this multiplication and accumulation might wrap around.
> 
> If the score wraps around to an artificially low value, would this cause
> DAMON's region merging logic to behave incorrectly due to unexpected
> thresholds?

It can overflow.  It doesn't make any critical cosnequences like kernel crash,
though.  Known low priority issue.

I'm considering avoiding this by adding the validation in the core layer
parameters validation, which is merged into mm-new today.


Thanks,
SJ

[...]

Re: [RFC PATCH 07/16] mm/damon/core: extend merge function to work with probe hits

[SJ Park]

On Sun, 05 Jul 2026 21:11:01 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> 
> New issues:
> - [High] Incompatible scale and domain mismatch between weighted scores and unweighted merge thresholds.
> - [High] Unsafe use of `abs()` macro on large unsigned integer score differences causes silent signed integer overflow.
> - [Medium] Calculating the weighted sum of probe hits in `damon_probe_hits_wsum` can easily overflow a 32-bit `unsigned int`.
> 
> Pre-existing issues:
> - [High] Weighted average calculations in `damon_merge_two_regions` silently overflow 32-bit `unsigned long` on 32-bit architectures.
> --
> 
> commit 54d6e0bb9900e63a1a016ffee9632b6aa602175b
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: extend merge function to work with probe hits
> 
> This commit extends damon_merge_regions_of() to consider the weighted sum
> of probe hits when calculating regions to merge, introducing
> damon_has_probe_weights() and modifying the scoring logic to use these weights.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index c370eaff5795d..f6e03746b170e 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > @@ -3187,6 +3192,16 @@ static void damon_merge_two_regions(struct damon_target *t,
> >  	damon_destroy_region(r, t);
> >  }
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but can the weighted average
> calculations in damon_merge_two_regions() silently overflow a 32-bit
> unsigned long on 32-bit architectures?
> 
> On 32-bit architectures, sz_l is a 32-bit unsigned long.
> 
> If the region size is large (e.g., hundreds of megabytes), multiplying sz_l
> by nr_accesses or probe_hits could exceed the 4.29B maximum of a 32-bit
> integer, corrupting the merged region's statistics.
> 
> mm/damon/core.c:damon_merge_two_regions() {
> ...
> 	l->nr_accesses = (l->nr_accesses * sz_l + r->nr_accesses * sz_r) /
> 			(sz_l + sz_r);
> ...
> 	for (i = 0; i < DAMON_MAX_PROBES; i++)
> 		l->probe_hits[i] = (l->probe_hits[i] * sz_l + r->probe_hits[i]
> 				* sz_r) / (sz_l + sz_r);
> ...
> }

This doesn't cause a critical consequenes like kernel crash.  Knnown low
priority issue.

> 
> > +static unsigned int damon_merge_score(struct damon_region *r, bool last,
> > +		struct damon_ctx *ctx, bool use_probe_hits)
> > +{
> > +	if (use_probe_hits)
> > +		return damon_probe_hits_wsum(r, last, ctx);
> 
> [Severity: Medium]
> Can the multiplication in damon_probe_hits_wsum() overflow a 32-bit
> unsigned int?
> 
> probe->weight is an unsigned int.
> 
> If users supply a large weight, multiplying it by r->probe_hits[i] (which can
> be up to 255) might exceed UINT_MAX, causing the sum to wrap around and yield
> artificially small scores for highly active regions.
> 
> mm/damon/core.c:damon_probe_hits_wsum() {
> ...
> 		if (last)
> 			sum += r->last_probe_hits[i++] * probe->weight;
> 		else
> 			sum += r->probe_hits[i++] * probe->weight;
> ...
> }

No critical consequence like kernel crash.  Known low priority issue.

> 
> > +	if (last)
> > +		return r->last_nr_accesses;
> > +	return r->nr_accesses;
> > +}
> > +
> >  /*
> >   * Merge adjacent regions having similar access frequencies
> >   *
> > @@ -3195,24 +3210,37 @@ static void damon_merge_two_regions(struct damon_target *t,
> >   * sz_limit	size upper limit of each region
> >   */
> >  static void damon_merge_regions_of(struct damon_target *t, unsigned int thres,
> > -				   unsigned long sz_limit)
> > +		unsigned long sz_limit, struct damon_ctx *ctx)
> >  {
> >  	struct damon_region *r, *prev = NULL, *next;
> > +	bool use_probe_hits = damon_has_probe_weights(ctx);
> >  
> >  	damon_for_each_region_safe(r, next, t) {
> > -		if (abs(r->nr_accesses - r->last_nr_accesses) > thres)
> > +		unsigned int score, last_score;
> > +
> > +		score = damon_merge_score(r, false, ctx, use_probe_hits);
> > +		last_score = damon_merge_score(r, true, ctx, use_probe_hits);
> > +
> > +		if (abs(score - last_score) > thres)
> 
> [Severity: High]
> Does the use of abs() here cause a silent signed integer overflow for large
> unsigned differences?
> 
> The macro abs() implicitly casts an unsigned int to a signed int.
> 
> If the mathematical difference between score and last_score exceeds INT_MAX
> (which might happen with large user-defined probe weights), the cast wraps to
> a negative number.
> 
> The abs() macro then negates it into an artificially small positive integer,
> which could cause the code to incorrectly bypass the > thres check and merge
> regions with vastly different access profiles.

Pre-existing issue.  I will fix this separately.

> 
> [Severity: High]
> Is there a domain mismatch between the weighted score differences and the
> unweighted thres parameter?
> 
> When use_probe_hits is true, the score is a weighted sum derived from probe
> hits and user-defined weights. However, thres operates in the unweighted access
> frequency domain.
> 
> This mismatch appears to carry over to kdamond_merge_regions(), where max_thres
> is also scaled in the unweighted domain (aggr_interval / sample_interval).
> 
> Because weighted scores operate in a different numerical domain, could they
> easily exceed max_thres, forcing the merge loop in kdamond_merge_regions() to
> terminate prematurely?
> 
> mm/damon/core.c:kdamond_merge_regions() {
> ...
> 	max_thres = c->attrs.aggr_interval /
> 		(c->attrs.sample_interval ?  c->attrs.sample_interval : 1);
> 	do {
> ...
> 		threshold = max(1, threshold * 2);
> 	} while (nr_regions > c->attrs.max_nr_regions &&
> 			threshold / 2 < max_thres);
> ...
> }

Yes, and that will be fixed by the later commit of this series.

> 
> >  			r->age = 0;
> > -		else if ((r->nr_accesses == 0) != (r->last_nr_accesses == 0))
> > +		else if ((score == 0) != (last_score == 0))
> >  			r->age = 0;
> >  		else
> >  			r->age++;
> >  
> > -		if (prev && prev->ar.end == r->ar.start &&
> > -		    abs(prev->nr_accesses - r->nr_accesses) <= thres &&
> > -		    damon_sz_region(prev) + damon_sz_region(r) <= sz_limit)
> > -			damon_merge_two_regions(t, prev, r);
> > -		else
> > -			prev = r;
> > +		if (!prev)
> > +			goto set_prev_continue;
> > +		if (prev->ar.end != r->ar.start)
> > +			goto set_prev_continue;
> > +		if (abs(damon_merge_score(prev, false, ctx, use_probe_hits) -
> > +					score) > thres)
> 
> [Severity: High]
> Does this abs() usage also suffer from the same silent signed integer overflow
> as mentioned above when comparing large unsigned score differences?

Pre-existing issue.  I will separately work on this.

> 
> > +			goto set_prev_continue;
> > +		if (damon_sz_region(prev) + damon_sz_region(r) > sz_limit)
> > +			goto set_prev_continue;
> > +		damon_merge_two_regions(t, prev, r);
> > +		continue;
> > +set_prev_continue:
> > +		prev = r;
> >  	}
> >  }
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=7


Thanks,
SJ

Re: [RFC PATCH 11/16] mm/damon/core: get merge threshold from probe hits when weights are set

[SJ Park]

On Sun, 05 Jul 2026 21:12:08 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [High] The merge threshold limit (`max_thres`) in `kdamond_merge_regions` is not scaled for probe weights, causing premature termination of the region merging loop and failing to enforce the user-defined `max_nr_regions` limit.
> 
> Pre-existing issues:
> - [High] When probe weights are configured for operations that do not implement `apply_probes` (e.g., `vaddr`), the merge threshold becomes 0 and regions are improperly and aggressively merged.
> --
> 
> commit 23bf451408faae1b0a1f1eb841dc6f4b60077861
> Author: SJ Park <sj@kernel.org>
> Subject: mm/damon/core: get merge threshold from probe hits when weights are set
> 
> When probe weights are set, DAMON merges regions based on their probe hits
> weighted sum, but the merge threshold is calculated based on access frequency.
> Update it to retrieve the maximum probe hits weighted sum in the snapshot from
> the apply_probes() ops callback, and generate the threshold based on it.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index bd6d836f1db5e..7a070cfb7cd1b 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -3683,9 +3684,18 @@ static int kdamond_fn(void *data)
> >  
> >  		if (!access_check_disabled && ctx->ops.check_accesses)
> >  			max_merge_score = ctx->ops.check_accesses(ctx);
> > -		if (ctx->ops.apply_probes)
> > -			ctx->ops.apply_probes(ctx, access_check_disabled,
> > -					false);
> > +		if (ctx->ops.apply_probes) {
> > +			if (time_after_eq(ctx->passed_sample_intervals,
> > +						next_aggregation_sis) &&
> > +					access_check_disabled)
> > +				get_max_wsum = true;
> > +			else
> > +				get_max_wsum = false;
> > +			max_wsum = ctx->ops.apply_probes(ctx,
> > +					access_check_disabled, get_max_wsum);
> > +			if (get_max_wsum)
> > +				max_merge_score = max_wsum;
> > +		}
> 
> [Severity: High]
> This is a pre-existing issue, but what happens if a user configures probe
> weights for operations that do not implement apply_probes (like vaddr)?
> 
> When damon_has_probe_weights() returns true, access checks are disabled. If
> the operations lack an apply_probes callback, max_merge_score will remain 0.
> 
> Will this cause all regions to be improperly and unconditionally merged into
> maximum-sized chunks, resulting in a loss of monitoring resolution?

Correct, and that's no problem.  Users who wrongly configured DAMON get poor
output.  As long as no critical consequences like kernel crash or memory leaks
happen, I believe this is fine.

> 
> [Severity: High]
> Does kdamond_merge_regions() properly handle this new weight-based score limit?
> 
> Just after this block, max_merge_score is passed into kdamond_merge_regions():
> 
> mm/damon/core.c:kdamond_fn() {
>     ...
> 		if (time_after_eq(ctx->passed_sample_intervals,
> 					next_aggregation_sis)) {
> 			kdamond_merge_regions(ctx,
> 					max_merge_score / 10,
> 					sz_limit);
>     ...
> }
> 
> Because max_thres inside kdamond_merge_regions() is hardcoded to the maximum
> possible frequency of unweighted accesses, rather than dynamically accounting
> for probe weights, the scaling loop termination condition:
> 
> mm/damon/core.c:kdamond_merge_regions() {
> 	...
> 	} while (nr_regions > c->attrs.max_nr_regions &&
> 			threshold / 2 < max_thres);
> 	...
> }
> 
> appears to instantly fail when the initial threshold is already large due to
> probe weights.
> 
> Will this cause an early abort of the fallback loop, leaving regions unmerged
> and failing to enforce the max_nr_regions limit?

Yes, and the later patch in this series will fix it.  Also, to make it no real
issue even before the later patch, we set thee mode detection to say no.  So
the issue cannot happen in the real world.

> 
> >  
> >  		if (time_after_eq(ctx->passed_sample_intervals,
> >  					next_aggregation_sis)) {
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=11


Thanks,
SJ

Re: [RFC PATCH 12/16] mm/damon/core: implement damon_has_probe_weight()

[SJ Park]

On Sun, 05 Jul 2026 21:15:52 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> 
> New issues:
> - [High] `damon_has_probe_weights()` returns `true` even for DAMON contexts that do not implement the `apply_probes` operation callback (e.g., `vaddr` and `fvaddr`), causing DAMON to silently bypass access checks and completely stop monitoring memory.
> 
> Pre-existing issues:
> - [High] Integer overflow in `abs()` macro usage with large unsigned probe scores breaks DAMON region merging.
> - [High] Multiplication overflow in `damon_merge_two_regions` when calculating merged probe hits and access counts on 32-bit systems.
> --
> 
> commit 4b421534e3283ef89ac2afef3f02956b0510da1e
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: implement damon_has_probe_weight()
>     
> DAMON monitors only data attributes when probe weights are set. However,
> the function for detecting it is intentionally returning false always.
> Now all the building blocks are made. Complete the mode detection function
> so that the mode can really start working.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 7a070cfb7cd1b..c7de55865b9c9 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -211,6 +211,12 @@ static struct damon_probe *damon_nth_probe(int n, struct damon_ctx *ctx)
> >  
> >  static bool damon_has_probe_weights(struct damon_ctx *c)
> >  {
> > +	struct damon_probe *p;
> > +
> > +	damon_for_each_probe(p, c) {
> > +		if (p->weight)
> > +			return true;
> > +	}
> 
> [Severity: High]
> Does this code need to check if the underlying ops struct supports probes?
> 
> If a context like vaddr or fvaddr has a probe weight configured via sysfs,
> this will return true. This causes access_check_disabled to be set to true in
> kdamond_fn(), which skips check_accesses():
> 
> mm/damon/core.c:kdamond_fn() {
>     ...
>     bool access_check_disabled = damon_has_probe_weights(ctx);
>     ...
> }
> 
> Because ctx->ops.apply_probes is NULL for vaddr, the apply block is then
> skipped and max_merge_score remains 0, which causes kdamond_merge_regions()
> to aggressively merge everything with a threshold of 0.

Yes, and no problem.  Users wrongly configure DAMON will get poor quality of
outputs.  No real bad consequences like kernel crash or memory leak happen.

> 
> >  	return false;
> >  }
> 
> I also noticed a couple of pre-existing issues in this file:
> 
> [Severity: High]
> This is a pre-existing issue, but does this code overflow the 32-bit
> boundary on 32-bit systems?
> 
> mm/damon/core.c:damon_merge_two_regions() {
> [ ... ]
> 	l->nr_accesses = (l->nr_accesses * sz_l + r->nr_accesses * sz_r) /
> 			(sz_l + sz_r);
> [ ... ]
> 	for (i = 0; i < DAMON_MAX_PROBES; i++)
> 		l->probe_hits[i] = (l->probe_hits[i] * sz_l + r->probe_hits[i]
> 				* sz_r) / (sz_l + sz_r);
> [ ... ]
> }
> 
> If a region size reaches around 42MB on a 32-bit architecture and
> nr_accesses is around 100, the multiplication nr_accesses * sz_l could
> exceed 4.2 billion and silently overflow the 32-bit unsigned long,
> corrupting the memory access statistics for merged regions.

Known low priority issue.  On 32-bit architectures users could use the
addr_unit parameter to avoid this.

> 
> [Severity: High]
> This is a pre-existing issue, but can the absolute difference of two large
> unsigned integers be evaluated incorrectly here?
> 
> mm/damon/core.c:damon_merge_regions_of() {
> [ ... ]
> 		score = damon_merge_score(r, false, ctx, use_probe_hits);
> 		last_score = damon_merge_score(r, true, ctx, use_probe_hits);
> 
> 		if (abs(score - last_score) > thres)
> 			r->age = 0;
> [ ... ]
> }
> 
> If a user configures a large probe weight via sysfs such that the weighted
> sum exceeds INT_MAX, score - last_score produces a large unsigned int. The
> abs() macro explicitly casts unsigned types to signed types, which would
> wrap into a negative signed integer and then be negated into a much smaller
> positive value. This could bypass the greater than threshold check and
> prevent regions from resetting their age.

Pre-existing issue.  I will separately work on this.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=12


Thanks,
SJ

Re: [RFC PATCH 14/16] Docs/mm/damon/design: document attrs-only monitoring

[SJ Park]

On Sun, 05 Jul 2026 21:05:19 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Spelling mistakes in the newly added documentation: 'deeecided' and 'mechaanism'.
> --
> 
> commit 802f6df741c5d3bfcb1ed21eadbf33ebee4db496
> Author: SJ Park <sj@kernel.org>
> 
> Docs/mm/damon/design: document attrs-only monitoring
> 
> This commit updates the DAMON design document to include a section
> describing the data attributes-only monitoring mode.
> 
> > diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
> > index 457d6e8bc7878..67398e2133036 100644
> > --- a/Documentation/mm/damon/design.rst
> > +++ b/Documentation/mm/damon/design.rst
> 
> [ ... ]
> 
> > @@ -316,6 +316,26 @@ Another way to do this for higher accuracy is using :ref:`DAMOS filter
> >  information in page level.  But, because it is operated in page level, the
> >  overhead is proportional to the size of the memory.
> >  
> > +Data Attributes-only Monitoring
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Data access is the primary monitoring information for DAMON.  Hence it
> > +:ref:`adjusts <damon_design_data_attrs_monitoring>` regions using the access
> > +:ref:`counter <damon_design_region_based_sampling>` (``nr_accesses``).  In some
> > +use cases, however, users may want some of :ref:`attributes
> > +<damon_design_data_attrs_monitoring>` to be the primary information.
> > +
> > +Data attributes-only monitoring mode supports this use case.  For the mode,
> > +each attribute probe has their priority weight value.  Users can describe by
> > +what combination of the attributes the primary information is deeecided, by
> 
> [Severity: Low]
> This isn't a bug, but there is a typo here: "deeecided" should be "decided".

Good finding.  I will fix this in the next revision.

> 
> > +setting the priority weight value.  If the total sum of the weights is not
> > +zero, the mode is enabled.  The regions adjustment mechaanism uses the weighted
> 
> [Severity: Low]
> This isn't a bug, but there is another typo here: "mechaanism" should be
> "mechanism".

Ditto.

> 
> > +sum of the :ref:`probe hit counts <damon_design_data_attrs_monitoring>` instead
> > +of ``nr_accesses`` in the case.  When the mode is enabled, access monitoring is
> > +automatically turned off.  The access counter (``nr_accesses``) will always be
> > +zero and not updated.  Hence the mode is called Data Attributes "only"
> > +monitoring.
> > +
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=14


Thanks,
SJ

Re: [RFC PATCH 15/16] Docs/admin-guide/mm/damon/usage: document weight sysfs file

[SJ Park]

On Sun, 05 Jul 2026 21:07:06 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Misspelled word 'atttributes' with three 't's in the added documentation.
> --
> 
> commit 0678cc4de62904aa4e60ad181dd2e6c07336bf2d
> Author: SJ Park <sj@kernel.org>
> 
> Docs/admin-guide/mm/damon/usage: document weight sysfs file
> 
> This commit updates the DAMON usage document to include the newly added
> probe weight file.
> 
> > diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
> > index b2649ea011f93..4515088eba968 100644
> > --- a/Documentation/admin-guide/mm/damon/usage.rst
> > +++ b/Documentation/admin-guide/mm/damon/usage.rst
> 
> [ ... ]
> 
> > @@ -286,6 +287,10 @@ In each probe directory, one directory, ``filters`` exists.  The directory
> >  contains files for installing filters for the probe, that is used to determine
> >  the data attribute for the probe.
> >  
> > +Each probe directory also contains ``weight`` file.  Reading from and writing
> > +to the file gets and sets the :ref:`atttributes-only monitoring
> 
> [Severity: Low]
> This isn't a bug, but there is a typo here. The word attributes is misspelled
> with three ts.

Good finding, I will fix this in the next revision.

> 
> > +<damon_design_attrs_only_monitoring>` weight for the attribute of the probe.
> > +
> >  In the beginning, ``filters`` directory has only one file, ``nr_filters``.
> >  Writing a number (``N``) to the file creates the number of child directories
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260705205743.98656-1-sj@kernel.org?part=15


Thanks,
SJ