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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8b8e9dde-33ff-41f7-8563-d9aeaf5efeb5@huawei-partners.com>
Date: Wed, 4 Feb 2026 16:07:40 +0300
From: Gutierrez Asier <gutierrez.asier@...wei-partners.com>
To: SeongJae Park <sj@...nel.org>
CC: <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 2/4/2026 10:17 AM, SeongJae Park wrote:
> 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?

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