From: Gutierrez Asier <gutierrez.asier@huawei-partners.com>
To: SeongJae Park <sj@kernel.org>
Cc: <artem.kuzin@huawei.com>, <stepanov.anatoly@huawei.com>,
<wangkefeng.wang@huawei.com>, <yanquanmin1@huawei.com>,
<zuoze1@huawei.com>, <damon@lists.linux.dev>,
<akpm@linux-foundation.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v1 0/4] mm/damon: Support hot application detections
Date: Wed, 4 Feb 2026 16:07:40 +0300 [thread overview]
Message-ID: <8b8e9dde-33ff-41f7-8563-d9aeaf5efeb5@huawei-partners.com> (raw)
In-Reply-To: <20260204071712.16325-1-sj@kernel.org>
On 2/4/2026 10:17 AM, SeongJae Park wrote:
> On Tue, 3 Feb 2026 17:25:11 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
>
>> SeongJae,
>>
>> Thanks a lot for all the useful feedback.
>
> The pleasure is mine! :)
>
>>
>> One thing that I was not sure about while working on this patch set
>> is whether to have an external new module or adding the logic to
>> damon core. I mean, the hot application detecting can be useful for
>> all other modules and can improve DAMON performance.
>
> All exising non-sample DAMON modules are working for the physical address
> space. I hence finding no many opportunities to bring benefits of hot
> application detection to those.
>
> I agree the hot applications detection could be useful in general and creative
> DAMON use cases for virtual address spaces. Implementing the feature in DAMON
> core layer and exposing it via DAMON sysfs interface will help such use cases.
> But it seems not straightforward to imagine how the sysfs interface can be
> extended for the feature.
>
> So, I think it would better to be implemented inside the new module at the
> moment. Later, if we end up having more modules that use the feature, we could
> move it to the modules-common or the core. If we further find a good way to
> integrate that with sysfs interface, definitely it could go to core.
>
> From this point, however, I realize the feature can also be implemented in the
> user sapce in a pretty straightforward way. Have you considered that?
I though about it. However, accessing the task_struct directly and extracting
the utime is much more efficient that getting the required info from the user
space.
>
>> What do you think?
>> My implementation was module based because I tried to avoid changes
>> to DAMON core for the RFC.
>
> If there is a good reason to implement that not in the user space but the
> kernel space, as I mentioned above, it seems the module is the right place to
> me.
>
>
> Thanks,
> SJ
>
> [...]
>
--
Asier Gutierrez
Huawei
next prev parent reply other threads:[~2026-02-04 13:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 14:56 gutierrez.asier
2026-02-02 14:56 ` [RFC PATCH v1 1/4] mm/damon: Generic context creation for modules gutierrez.asier
2026-02-03 1:16 ` SeongJae Park
2026-02-03 13:04 ` Gutierrez Asier
2026-02-02 14:56 ` [RFC PATCH v1 2/4] mm/damon: Support for synchrounous huge pages collapse gutierrez.asier
2026-02-03 1:23 ` SeongJae Park
2026-02-03 14:04 ` Gutierrez Asier
2026-02-02 14:56 ` [RFC PATCH v1 3/4] mm/damon: New module with hot application detection gutierrez.asier
2026-02-03 5:04 ` SeongJae Park
2026-02-03 14:21 ` Gutierrez Asier
2026-02-02 14:56 ` [RFC PATCH v1 4/4] documentation/mm/damon: Documentation for the dynamic_hugepages module gutierrez.asier
2026-02-03 5:34 ` SeongJae Park
2026-02-03 1:10 ` [RFC PATCH v1 0/4] mm/damon: Support hot application detections SeongJae Park
2026-02-03 13:03 ` Gutierrez Asier
2026-02-04 7:31 ` SeongJae Park
2026-02-03 14:25 ` Gutierrez Asier
2026-02-04 7:17 ` SeongJae Park
2026-02-04 13:07 ` Gutierrez Asier [this message]
2026-02-04 15:43 ` SeongJae Park
2026-02-11 6:59 ` SeongJae Park
2026-02-11 11:29 ` Gutierrez Asier
2026-02-11 15:09 ` SeongJae Park
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=8b8e9dde-33ff-41f7-8563-d9aeaf5efeb5@huawei-partners.com \
--to=gutierrez.asier@huawei-partners.com \
--cc=akpm@linux-foundation.org \
--cc=artem.kuzin@huawei.com \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj@kernel.org \
--cc=stepanov.anatoly@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=yanquanmin1@huawei.com \
--cc=zuoze1@huawei.com \
/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