Hello SJ，

1、kdamond monitors physical/virtual addresses and performs certain actions based
on the monitoring results to improve system/process efficiency. When the system
undergoes suspend/resume, most user-space processes are in a suspended state.
kdamond may therefore perform operations such as PAGEOUT / MADV_NOHUGEPAGE, but
these are not true data monitoring results. This may cause changes in the efficiency
of certain processes after system resume. Therefore, I believe that continuing to
run kdamond during suspend is meaningless and may even have negative effects.

2、When performing hibernate, most of the used memory in the system is swapped out to
disk. When memory is large, this is time-consuming. If kdamond does not sleep, it may
affect hibernate efficiency.

3、As discussed in [1]: "The principal reason is to prevent filesystems from being damaged
after hibernation. At the moment we have no simple means of checkpointing filesystems, so if
there are any modifications made to filesystem data and/or metadata on disks, we cannot bring
them back to the state from before the modifications. At the same time each hibernation image
contains some filesystem-related information that must be consistent with the state of the on
disk data and metadata after the system memory state has been restored from the image (otherwise
the filesystems will be damaged in a nasty way, usually making them almost impossible to repair).
We therefore freeze tasks that might cause the on-disk filesystems' data and metadata to be modified
after the hibernation image has been created and before the system is finally powered off. The majority
of these are user space processes, but if any of the kernel threads may cause something like this to
happen, they have to be freezable." During suspend/resume, processes involving I/O operations should
be frozen.

Based on the above reasons, I believe it is reasonable to support freezing kdamond. If there are any
errors in my thinking, please point them out.

Thans,
Lin Ruifeng

Hello Lin,


Thank you for sharing this patch.

On Wed, 8 Apr 2026 16:06:52 +0800 Lin Ruifeng <linruifeng4@huawei.com> wrote:

During suspend and resume, the data monitored by kdamond is
no longer meaningful. Meanwhile, since kdamond may involve
I/O operations, it is necessary to freeze it.

I'm not used to PM freezer, and maybe because of that, I'm not fully
understanding the motivation of this patch.  Could you please elaborate the
existing problem and how this patch is fixing or improving it?


Thanks,
SJ

Signed-off-by: Lin Ruifeng <linruifeng4@huawei.com>
---
 mm/damon/core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 3e1890d64d06..5cd1f0aed66b 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -16,6 +16,7 @@
 #include <linux/slab.h>
 #include <linux/string.h>
 #include <linux/string_choices.h>
+#include <linux/freezer.h>
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/damon.h>
@@ -2753,6 +2754,7 @@ static int kdamond_fn(void *data)
 
 	complete(&ctx->kdamond_started);
 	kdamond_init_ctx(ctx);
+	set_freezable();
 
 	if (ctx->ops.init)
 		ctx->ops.init(ctx);
@@ -2774,6 +2776,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;
 
+		try_to_freeze();
+
 		if (kdamond_wait_activation(ctx))
 			break;
 
-- 
2.43.0