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

[SeongJae Park <sj@kernel.org>]

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

[...]