[PATCH] mm/damon: support freeze kdamond

[PATCH] mm/damon: support freeze kdamond

[Lin Ruifeng]

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.

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

Re: [PATCH] mm/damon: support freeze kdamond

[SeongJae Park]

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

Re: [PATCH] mm/damon: support freeze kdamond

[linruifeng (A)]

Hello SJ，

Thank you for your reply. Based on my current knowledge, I think this can be
described from three aspects:

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

在 2026/4/8 22:07, SeongJae Park 写道:
> 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

Re: [PATCH] mm/damon: support freeze kdamond

[SeongJae Park]

On Thu, 9 Apr 2026 15:20:10 +0800 "linruifeng (A)" <linruifeng4@huawei.com> wrote:

> Hello SJ，
> 
> Thank you for your reply. Based on my current knowledge, I think this can be
> described from three aspects:
> 
> 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.

Sounds making sense, but I'm failing at finding some specific problematic case
and expecting the real impact.  Can you share a concrete problematic scenario
example with an expectation of the impact?  Also, is this just a theoretical
concern?  Or, a real issue that you find from your real DAMON use case?  If
this is finding from a real use case, could you addd more details about the
observation?

> 
> 3、As discussed in [1]:

Seems you forgot adding a link?

> "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.

But what file system changes DAMON could make?  Could you please add more
detailed scenarios and expectation or observation of the impact?

> 
> 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.

I feel like it is reasonable but I'd love it more if there are more concrete
examples and/or observations that support this.


Thanks,
SJ

[...]