[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260204071712.16325-1-sj@kernel.org>
Date: Tue, 3 Feb 2026 23:17:11 -0800
From: SeongJae Park <sj@...nel.org>
To: Gutierrez Asier <gutierrez.asier@...wei-partners.com>
Cc: SeongJae Park <sj@...nel.org>,
artem.kuzin@...wei.com,
stepanov.anatoly@...wei.com,
wangkefeng.wang@...wei.com,
yanquanmin1@...wei.com,
zuoze1@...wei.com,
damon@...ts.linux.dev,
akpm@...ux-foundation.org,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/4] mm/damon: Support hot application detections
On Tue, 3 Feb 2026 17:25:11 +0300 Gutierrez Asier <gutierrez.asier@...wei-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?
> 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
[...]
Powered by blists - more mailing lists