From: Honggyu Kim <honggyu.kim@sk.com>
To: SeongJae Park <sj@kernel.org>
Cc: kernel_team@skhynix.com,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
damon@lists.linux.dev, kernel-team@meta.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 0/4] mm/damon/sysfs: support periodic and automated stats update
Date: Wed, 16 Jul 2025 14:18:48 +0900 [thread overview]
Message-ID: <4c83fac5-0990-4280-9a21-969d83582112@sk.com> (raw)
In-Reply-To: <20250716025118.92544-1-sj@kernel.org>
On 7/16/2025 11:51 AM, SeongJae Park wrote:
> On Wed, 16 Jul 2025 10:58:06 +0900 Honggyu Kim <honggyu.kim@sk.com> wrote:
>
>> 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.
[...snip...]
>>>>> 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 guess you are saying about sysfs files? Yes, I think listing those all is
> unnecessary.
OK. No problem then.
>>> 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,
>
> Assuming "knobs" mean sysfs files, this is incorrect. Writing "commit" to
> "state" passes the parameters written on appropriate files to running kdamond.
> It doesn't update any sysfs files until a "update_*" keyword is written to the
> "state" file.
I thought writing "commit" to "state" applies config changes and updates all the
readable sysfs files together, but it doesn't. Thanks for the correction.
>
>> 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.
>
> Thank you for this nice question. Yes. Enabling "refresh_ms" is roughly same
> to periodically writing
> "update_{tuned_intervals,schemes_stats,schemes_effective_quotas" to "state"
> file.
OK. I get that "refresh_ms" does periodic write the combination of them to
"state" without "update_{schemes_tried_regions,schemes_tried_bytes}.
In other words, it is same as periodic execution of the follows.
echo update_tuned_intervals > state
echo update_schemes_stats > state
echo update_schemes_effective_quotas > state
That makes my question clear. Thanks for the explanation!
Thanks,
Honggyu
>
>
> Thanks,
> SJ
>
> [...]
prev parent reply other threads:[~2025-07-16 5:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 20:46 SeongJae Park
2025-07-12 20:46 ` [RFC PATCH 1/4] mm/damon/sysfs: implement refresh_ms file under kdamond directory SeongJae Park
2025-07-12 20:46 ` [RFC PATCH 2/4] mm/damon/sysfs: implement refresh_ms file internal work SeongJae Park
2025-07-12 20:46 ` [RFC PATCH 3/4] Docs/admin-guide/mm/damon/usage: document refresh_ms file SeongJae Park
2025-07-12 20:46 ` [RFC PATCH 4/4] Docs/ABI/damon: update for refresh_ms SeongJae Park
2025-07-15 22:20 ` [RFC PATCH 0/4] mm/damon/sysfs: support periodic and automated stats update Honggyu Kim
2025-07-15 23:43 ` SeongJae Park
2025-07-16 1:58 ` Honggyu Kim
2025-07-16 2:51 ` SeongJae Park
2025-07-16 5:18 ` Honggyu Kim [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c83fac5-0990-4280-9a21-969d83582112@sk.com \
--to=honggyu.kim@sk.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=damon@lists.linux.dev \
--cc=kernel-team@meta.com \
--cc=kernel_team@skhynix.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox