linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Gutierrez Asier <gutierrez.asier@huawei-partners.com>
Cc: SeongJae Park <sj@kernel.org>,
	artem.kuzin@huawei.com, stepanov.anatoly@huawei.com,
	wangkefeng.wang@huawei.com, yanquanmin1@huawei.com,
	zuoze1@huawei.com, damon@lists.linux.dev,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 0/4] mm/damon: Support hot application detections
Date: Tue,  3 Feb 2026 23:17:11 -0800	[thread overview]
Message-ID: <20260204071712.16325-1-sj@kernel.org> (raw)
In-Reply-To: <af4f3e15-a306-4728-b5bf-1deaa700c99b@huawei-partners.com>

On Tue, 3 Feb 2026 17:25:11 +0300 Gutierrez Asier <gutierrez.asier@huawei-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

[...]


  reply	other threads:[~2026-02-04  7:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-02 14:56 gutierrez.asier
2026-02-02 14:56 ` [RFC PATCH v1 1/4] mm/damon: Generic context creation for modules gutierrez.asier
2026-02-03  1:16   ` SeongJae Park
2026-02-03 13:04     ` Gutierrez Asier
2026-02-02 14:56 ` [RFC PATCH v1 2/4] mm/damon: Support for synchrounous huge pages collapse gutierrez.asier
2026-02-03  1:23   ` SeongJae Park
2026-02-03 14:04     ` Gutierrez Asier
2026-02-02 14:56 ` [RFC PATCH v1 3/4] mm/damon: New module with hot application detection gutierrez.asier
2026-02-03  5:04   ` SeongJae Park
2026-02-03 14:21     ` Gutierrez Asier
2026-02-02 14:56 ` [RFC PATCH v1 4/4] documentation/mm/damon: Documentation for the dynamic_hugepages module gutierrez.asier
2026-02-03  5:34   ` SeongJae Park
2026-02-03  1:10 ` [RFC PATCH v1 0/4] mm/damon: Support hot application detections SeongJae Park
2026-02-03 13:03   ` Gutierrez Asier
2026-02-04  7:31     ` SeongJae Park
2026-02-03 14:25   ` Gutierrez Asier
2026-02-04  7:17     ` SeongJae Park [this message]
2026-02-04 13:07       ` Gutierrez Asier
2026-02-04 15:43         ` SeongJae Park
2026-02-11  6:59 ` SeongJae Park
2026-02-11 11:29   ` Gutierrez Asier
2026-02-11 15:09     ` SeongJae Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260204071712.16325-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=artem.kuzin@huawei.com \
    --cc=damon@lists.linux.dev \
    --cc=gutierrez.asier@huawei-partners.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=stepanov.anatoly@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=yanquanmin1@huawei.com \
    --cc=zuoze1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox