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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250715234316.91272-1-sj@kernel.org>
Date: Tue, 15 Jul 2025 16:43:16 -0700
From: SeongJae Park <sj@...nel.org>
To: Honggyu Kim <honggyu.kim@...com>
Cc: SeongJae Park <sj@...nel.org>,
	kernel_team@...ynix.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>,
	damon@...ts.linux.dev,
	kernel-team@...a.com,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: 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 <honggyu.kim@...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.

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

[...]