On Wed, 16 Jul 2025 07:20:57 +0900 Honggyu Kim <honggyu.kim@xxxxxx> 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. 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 [...]
