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] [day] [month] [year] [list]

Message-ID: <20260204154321.18577-1-sj@kernel.org>
Date: Wed,  4 Feb 2026 07:43:20 -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 Wed, 4 Feb 2026 16:07:40 +0300 Gutierrez Asier <gutierrez.asier@...wei-partners.com> wrote:

> 
> 
> 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.

I agree it would be much more efficient to do that in the kernel space.  But,
given existence of 'top' like user space programs that also does similar works
and heavily used, I'm not directly feeling how important the efficiency is in
the real life.

Meanwhile, doing it in the user space (DAMON user-space tool or your own one)
would be simpler and more flexible.  For example, you could simply use 'ps
--sort=%cpu', and make the sorting algorithm flexible (e.g., sorting by RSS or
using different sorting algorithms) without changing kernel.

So there are pros and cons, to my humble view.  Those may depend on the given
use case, and I want to focus on your planned or expected use case.  Could you
please clarify your planned or expected use case, and how important and trivial
the pros and cons of keeping the logic in kernel or user space would be on the
scenarios?


Thanks,
SJ

[...]