Re: [RFC PATCH 0/4] mm/damon/sysfs: support periodic and automated stats update

On Wed, 16 Jul 2025 07:20:57 +0900 Honggyu Kim [off-list ref] wrote:

Hi SeongJae,

On 7/13/2025 5:46 AM, SeongJae Park wrote:

quoted

DAMON sysfs interface provides files for reading DAMON internal status
including DAMOS stats.  The content of the files are not automatically
updated, though.  Users should manually request updates of the contents
by writing a special command to 'state' file of each kdamond directory.
This interface is good for minimizing overhead, but causes the below
problems.

First, the usage is cumbersome.  This is arguably not a big problem,
since the user-space tool (damo) can do this instead of the user.

Second, it can be too slow.  The update request is not directly handled
by the sysfs interface but kdamond thread.  And kdamond threads wake up
only once per the sampling interval.  Hence if sampling interval is not
short, each update request could take too long time.  The recommended
sampling interval setup is asking DAMON to automatically tune it, within
a range between 5 milliseconds and 10 seconds.  On production systems it
is not very rare to have a few seconds sampling interval as a result of
the auto-tuning, so this can disturb observing DAMON internal status.

Finally, parallel update requests can conflict with each other.  When
parallel update requests are received, DAMON sysfs interface simply
returns -EBUSY to one of the requests.  DAMON user-space tool is hence
implementing its own backoff mechanism, but this can make the operation
even slower.

Introduce a new sysfs file, namely refresh_ms, for asking DAMON sysfs
interface to repeat the essential contents update with a user-specified
time delay.

Thanks for working on this, but I have a few questions.
1. Could you please list up what are the "essential contents"?

Thank you for asking this.  The contents are auto-tuned monitoring intervals,
DAMOS stats, and auto-tuned effective size quota.

I will add these on the next version cover letter.

2. Does it mean that it is different from writing "commit" to "state"?
3. If not, then is there equivalent action to writing something to "state"?

"refresh_ms" works same to other DAMON parameter files.  You can set it before
starting DAMON, or "commit" new values (including 0 for turning this refresh
off) in runtime.

I'm not that confident if I understood your point very well, especially what
"it"s mean.  Let me know if I'm misunderstanding something.

If possible, then this kind of information is better to be documented because
users might get confused if something isn't udpated when "refresh_ms" is set.

You're right!  I'll add above things on the next version of the cover letter.


Thanks,
SJ

[...]