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

["linruifeng (A)" <linruifeng4@huawei.com>]

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