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

Powered by Openwall GNU/*/Linux Powered by OpenVZ