[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4c83fac5-0990-4280-9a21-969d83582112@sk.com>
Date: Wed, 16 Jul 2025 14:18:48 +0900
From: Honggyu Kim <honggyu.kim@...com>
To: SeongJae Park <sj@...nel.org>
Cc: 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 7/16/2025 11:51 AM, SeongJae Park wrote:
> On Wed, 16 Jul 2025 10:58:06 +0900 Honggyu Kim <honggyu.kim@...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@...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
>
> [...]
Powered by blists - more mailing lists