Re: [RFC PATCH v1 0/4] mm/damon: Support hot application detections

[Gutierrez Asier]

On 2/4/2026 10:17 AM, SeongJae Park wrote:
> On Tue, 3 Feb 2026 17:25:11 +0300 Gutierrez Asier <gutierrez.asier@xxxxxxxxxxxxxxxxxxx> 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