Skip to contentSkip to conversation

mm/damon: fix wrong behaviors in DAMOS PSI goal and sysfs refresh_ms

PATCH In review SJ Park 2 participants 8 messages Aug 27

Subsystems (3)
lore
Share & tools
lore

SJ Park

author maintainer
#0 lore raw

cover mm/damon: fix wrong behaviors in DAMOS PSI goal and sysfs refresh_ms

PSI based DAMOS auto-tuning and DAMON sysfs refresh_ms file have bugs that can produce non critical but still unexpected behaviors. Fix the two bugs.

SJ Park (2):
mm/damon/core: initialize damos_quota_goal->last_psi_total mm/damon/sysfs: set next refresh jiffies per sysfs context

 mm/damon/core.c  | 16 +++++++++++++++-
 mm/damon/sysfs.c | 11 +++++------
 2 files changed, 20 insertions(+), 7 deletions(-)

base-commit: 3b3eb2976e2dadfd8624db7ba32ed28addb7e416

Signature · 1 line
2.47.3
author maintainer
#1 lore raw

PATCH 1/2 mm/damon/core: initialize damos_quota_goal->last_psi_total

When DAMOS_QUOTA_SOME_MEM_PSI_US metric damos quota goal is set, the PSI delta for the feedback loop is calculated using damos_quota_goal->last_psi_total. However, it is initialized only after the first feedback loop. The first iteration of the loop uses the uninitialized value. As a result, the feedback loop can change the effective quota in an unexpected way at the first iteration.

The user impact of the issue is not big, because the issue impacts only the first iteration of the feedback loop. The feedback loop also has an internal cap of the quota adjustment. The wrong adjustment will soon be corrected over a few iterations. For this reason, doing no initialization at commit time was intentional. It is also explicitly commented. That said, nobody likes behaviors that are unexpected or difficult to be expected. Fixing it is also simple and not expensive.

Initialize the field at the beginning of kdamond and each commit of SOME_MEM_PSI_US type quota goals.

The issue was discovered [1] by Sashiko.

[1] https://lore.kernel.org/[email protected]

Fixes 2dbb60f789cb ("mm/damon/core: implement PSI metric DAMOS quota goal")
Cc <[email protected]> # 6.9.x
---
 mm/damon/core.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)
mm/damon/core.c +15 -1
index f8dddbff74a77..0d4a571482fb9 100644
@@ -1122,6 +1122,9 @@ static void damos_commit_quota_goal_union(
 		struct damos_quota_goal *dst, struct damos_quota_goal *src)
 {
 	switch (dst->metric) {
+	case DAMOS_QUOTA_SOME_MEM_PSI_US:
+		dst->last_psi_total = damos_get_some_mem_psi_total();
+		break;
 	case DAMOS_QUOTA_NODE_MEM_USED_BP:
 	case DAMOS_QUOTA_NODE_MEM_FREE_BP:
 		dst->nid = src->nid;
@@ -1143,7 +1146,6 @@ static void damos_commit_quota_goal(
 	dst->target_value = src->target_value;
 	if (dst->metric == DAMOS_QUOTA_USER_INPUT)
 		dst->current_value = src->current_value;
-	/* keep last_psi_total as is, since it will be updated in next cycle */
 	damos_commit_quota_goal_union(dst, src);
 }
 
@@ -3741,6 +3743,17 @@ static int kdamond_wait_activation(struct damon_ctx *ctx)
 	return -EBUSY;
 }
 
+static void damos_init_quota_goal_last_psi(struct damos *s)
+{
+	struct damos_quota_goal *goal;
+
+	damos_for_each_quota_goal(goal, &s->quota) {
+		if (goal->metric != DAMOS_QUOTA_SOME_MEM_PSI_US)
+			continue;
+		goal->last_psi_total = damos_get_some_mem_psi_total();
+	}
+}
+
 static void kdamond_init_ctx(struct damon_ctx *ctx)
 {
 	unsigned long sample_interval = ctx->attrs.sample_interval ?
@@ -3757,6 +3770,7 @@ static void kdamond_init_ctx(struct damon_ctx *ctx)
 	damon_for_each_scheme(scheme, ctx) {
 		damos_set_next_apply_sis(scheme, ctx);
 		damos_set_filters_default_reject(scheme);
+		damos_init_quota_goal_last_psi(scheme);
 	}
 }
 
Signature · 1 line
2.47.3
#2 lore raw

Re: [PATCH 1/2] mm/damon/core: initialize damos_quota_goal->last_psi_total

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

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

New issues:
- [Low] Implicit declaration of function 'damos_get_some_mem_psi_total' causes a compilation error.

Pre-existing issues:
- [High] The DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric's 'nid' field is not copied when committing a quota goal parameter update, leading to an uninitialized node ID being used for eligible memory queries. --

commit 9597a197ecbd4f36e4fa8dfa9bd1bdbb5a5f1d93
Author: SJ Park <[email protected]>

mm/damon/core: initialize damos_quota_goal->last_psi_total

Initializes the last_psi_total field at the beginning of kdamond and during each commit for SOME_MEM_PSI_US type quota goals. This prevents unexpected adjustments during the first iteration of the feedback loop.

mm/damon/core.c static void damos_commit_quota_goal_union( · line 1126

Quoted 10 lines
mm/damon/core.c +2 -0
index 644daf5a16560..6f360d61390ad 100644
@@ -1122,6 +1122,9 @@ static void damos_commit_quota_goal_union(
 		struct damos_quota_goal *dst, struct damos_quota_goal *src)
 {
 	switch (dst->metric) {
+	case DAMOS_QUOTA_SOME_MEM_PSI_US:
+		dst->last_psi_total = damos_get_some_mem_psi_total();

[Severity: Low]
Does this cause a compilation error due to an implicit function declaration?

The function damos_get_some_mem_psi_total() is called here, but it appears to be defined later in mm/damon/core.c without a prior forward declaration.

mm/damon/core.c static void damos_commit_quota_goal_union( · line 1130

Quoted 4 lines
mm/damon/core.c +1 -0
+		break;
 	case DAMOS_QUOTA_NODE_MEM_USED_BP:
 	case DAMOS_QUOTA_NODE_MEM_FREE_BP:
 		dst->nid = src->nid;

[Severity: High]
This is a pre-existing issue, but does this switch statement omit the DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric?

When a user configures a DAMOS quota goal using the DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric via sysfs, a new quota goal is allocated in damos_new_quota_goal() via kmalloc_obj(), where the memory is not zeroed.

Because DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP is missing from the switch statement in damos_commit_quota_goal_union(), its nid field is not copied over during parameter updates. This leaves the node ID uninitialized and potentially causes eligible memory queries to evaluate using garbage data, completely breaking the metric's functionality.

[ ... ]

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
author maintainer
#3 lore raw

Re: [PATCH 1/2] mm/damon/core: initialize damos_quota_goal->last_psi_total

Quoted 34 lines · On Thu, 27 Aug 2026 04:45:47 +0000 [email protected] wrote:

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

New issues:
- [Low] Implicit declaration of function 'damos_get_some_mem_psi_total' causes a compilation error.

Pre-existing issues:
- [High] The DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric's 'nid' field is not copied when committing a quota goal parameter update, leading to an uninitialized node ID being used for eligible memory queries. --

commit 9597a197ecbd4f36e4fa8dfa9bd1bdbb5a5f1d93
Author: SJ Park <[email protected]>

mm/damon/core: initialize damos_quota_goal->last_psi_total

Initializes the last_psi_total field at the beginning of kdamond and during each commit for SOME_MEM_PSI_US type quota goals. This prevents unexpected adjustments during the first iteration of the feedback loop.

mm/damon/core.c static void damos_commit_quota_goal_union( · line 1126

Quoted 10 lines
mm/damon/core.c +2 -0
index 644daf5a16560..6f360d61390ad 100644
@@ -1122,6 +1122,9 @@ static void damos_commit_quota_goal_union(
 		struct damos_quota_goal *dst, struct damos_quota_goal *src)
 {
 	switch (dst->metric) {
+	case DAMOS_QUOTA_SOME_MEM_PSI_US:
+		dst->last_psi_total = damos_get_some_mem_psi_total();

[Severity: Low]
Does this cause a compilation error due to an implicit function declaration?

Quoted 2 lines

The function damos_get_some_mem_psi_total() is called here, but it appears to be defined later in mm/damon/core.c without a prior forward declaration.

Good catch. I will add the declaration in the next version.

Quoted 15 lines

mm/damon/core.c static void damos_commit_quota_goal_union( · line 1130

Quoted 5 lines
mm/damon/core.c +1 -0
+		break;
 	case DAMOS_QUOTA_NODE_MEM_USED_BP:
 	case DAMOS_QUOTA_NODE_MEM_FREE_BP:
 		dst->nid = src->nid;

[Severity: High]
This is a pre-existing issue, but does this switch statement omit the DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric?

When a user configures a DAMOS quota goal using the DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric via sysfs, a new quota goal is allocated in damos_new_quota_goal() via kmalloc_obj(), where the memory is not zeroed.

Quoted 5 lines

Because DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP is missing from the switch statement in damos_commit_quota_goal_union(), its nid field is not copied over during parameter updates. This leaves the node ID uninitialized and potentially causes eligible memory queries to evaluate using garbage data, completely breaking the metric's functionality.

Good catch. I will separately work on this.

Quoted 5 lines

[ ... ]

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

Thanks,
SJ

author maintainer
#4 lore raw

Re: [PATCH 1/2] mm/damon/core: initialize damos_quota_goal->last_psi_total

Quoted 1 line · On Wed, 26 Aug 2026 21:50:34 -0700 SJ Park <[email protected]> wrote:

On Thu, 27 Aug 2026 04:45:47 +0000 [email protected] wrote:

[...]

Quoted 9 lines
Quoted 9 lines

[Severity: High]
This is a pre-existing issue, but does this switch statement omit the DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric?

When a user configures a DAMOS quota goal using the DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP metric via sysfs, a new quota goal is allocated in damos_new_quota_goal() via kmalloc_obj(), where the memory is not zeroed.

Quoted 7 lines
Quoted 5 lines

Because DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP is missing from the switch statement in damos_commit_quota_goal_union(), its nid field is not copied over during parameter updates. This leaves the node ID uninitialized and potentially causes eligible memory queries to evaluate using garbage data, completely breaking the metric's functionality.

Good catch. I will separately work on this.

Actually the fix will be quite straightforward. I will add that as a part of the next version of this series.

Thanks,
SJ

[...]

author maintainer
#5 lore raw

PATCH 2/2 mm/damon/sysfs: set next refresh jiffies per sysfs context

In reply to SJ Park

When 'refresh_ms' is set, DAMON sysfs interface periodically updates auto-tuned parameters and DAMOS stats. The timestamp for the next refresh is initialized when a DAMON context starts, and updated in its damon_call() callback function. That is, each DAMON context updates it. However, the timestamp is a global variable that is shared with all the contexts. When there are multiple DAMON contexts having different refresh_ms, the update frequency will be changed, depending on the order of the contexts. When there are multiple kdamonds, it will be even more chaotic. Fix the problem by having the timestamp per each context.

The user impact is not very critical. It does not leak, corrupt or crash. The update will not be faster or slower than the lowest and largest refresh_ms values of the contexts, respectively. The user can also manually ask the updates on demand using kdamond state commands. That said, clearly this is a bug.

Fixes 9fd7bb5083d1 ("mm/damon/sysfs: change next_update_jiffies to a global variable")
Cc <[email protected]> # 6.18.x
---
 mm/damon/sysfs.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)
mm/damon/sysfs.c +5 -6
index e3858ffab4b22..f05b256c90ee7 100644
@@ -1789,6 +1789,7 @@ struct damon_sysfs_kdamond {
 	struct damon_sysfs_contexts *contexts;
 	struct damon_ctx *damon_ctx;
 	unsigned int refresh_ms;
+	unsigned long next_refresh_jiffies;
 };
 
 static struct damon_sysfs_kdamond *damon_sysfs_kdamond_alloc(void)
@@ -2215,17 +2216,15 @@ static struct damon_ctx *damon_sysfs_build_ctx(
 	return ctx;
 }
 
-static unsigned long damon_sysfs_next_update_jiffies;
-
 static int damon_sysfs_repeat_call_fn(void *data)
 {
 	struct damon_sysfs_kdamond *sysfs_kdamond = data;
 
 	if (!sysfs_kdamond->refresh_ms)
 		return 0;
-	if (time_before(jiffies, damon_sysfs_next_update_jiffies))
+	if (time_before(jiffies, sysfs_kdamond->next_refresh_jiffies))
 		return 0;
-	damon_sysfs_next_update_jiffies = jiffies +
+	sysfs_kdamond->next_refresh_jiffies = jiffies +
 		msecs_to_jiffies(sysfs_kdamond->refresh_ms);
 
 	if (!mutex_trylock(&damon_sysfs_lock))
@@ -2273,8 +2272,8 @@ static int damon_sysfs_turn_damon_on(struct damon_sysfs_kdamond *kdamond)
 	}
 	kdamond->damon_ctx = ctx;
 
-	damon_sysfs_next_update_jiffies =
-		jiffies + msecs_to_jiffies(kdamond->refresh_ms);
+	kdamond->next_refresh_jiffies = jiffies +
+		msecs_to_jiffies(kdamond->refresh_ms);
 
 	repeat_call_control->fn = damon_sysfs_repeat_call_fn;
 	repeat_call_control->data = kdamond;
Signature · 1 line
2.47.3
#6 lore raw

Re: [PATCH 2/2] mm/damon/sysfs: set next refresh jiffies per sysfs context

Sashiko has reviewed this patch and found no issues. It looks great!
Quoted 16 lines

When 'refresh_ms' is set, DAMON sysfs interface periodically updates auto-tuned parameters and DAMOS stats. The timestamp for the next refresh is initialized when a DAMON context starts, and updated in its damon_call() callback function. That is, each DAMON context updates it. However, the timestamp is a global variable that is shared with all the contexts. When there are multiple DAMON contexts having different refresh_ms, the update frequency will be changed, depending on the order of the contexts. When there are multiple kdamonds, it will be even more chaotic. Fix the problem by having the timestamp per each context.

The user impact is not very critical. It does not leak, corrupt or crash. The update will not be faster or slower than the lowest and largest refresh_ms values of the contexts, respectively. The user can also manually ask the updates on demand using kdamond state commands. That said, clearly this is a bug.

Quoted 3 lines
Fixes 9fd7bb5083d1 ("mm/damon/sysfs: change next_update_jiffies to a global variable")
Cc <[email protected]> # 6.18.x

Sashiko has reviewed this patch and found no issues. It looks great!

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
author maintainer
#7 lore raw
In reply to SJ Park

My intention was to send this as an RFC series. I forgot adding 'RFC' tag by a mistake. Sorry for noise. Andrew, could you please drop this series from mm-new for now?

Thanks,
SJ

[...]