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

[Honggyu Kim <honggyu.kim@sk.com>]

Hi SeongJae,

On 7/16/2025 8:43 AM, SeongJae Park wrote:
> On Wed, 16 Jul 2025 07:20:57 +0900 Honggyu Kim <honggyu.kim@sk.com> wrote:
> 
>> Hi SeongJae,
>>
>> On 7/13/2025 5:46 AM, SeongJae Park wrote:
>>> 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.

Thanks, but I meant the specific list of damon knobs refreshed.  If there are
too many knobs, then don't have to list them all.

> I will add these on the next version cover letter.

Thanks.

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

I mean writing "commit" to "state" refresh all knobs, but it seems "refresh_ms"
internally refresh paritial knobs so I was wondering what are refreshed and what 
aren't.

Regarding the "equivalent action", I was also wondering if there is a command
that works same as "refresh_ms" internally does among the command below.

   update_tuned_intervals
   commit_schemes_quota_goals
   update_schemes_stats
   update_schemes_tried_regions
   update_schemes_tried_bytes
   clear_schemes_tried_regions
   update_schemes_effective_quotas

https://docs.kernel.org/admin-guide/mm/damon/usage.html#kdamonds-n

In other words, if there is the same command listed above, then users might be
able to run a script that regularaly write the command to the current "state"
even without this "refresh_ms".  I know having "refresh_ms" is much better
though.

Thanks,
Honggyu

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