public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: 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 3/4] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing
Date: Thu, 30 Apr 2026 17:54:57 -0700	[thread overview]
Message-ID: <20260501005458.79180-1-sj@kernel.org> (raw)
In-Reply-To: <20260430134139.2446417-4-gutierrez.asier@huawei-partners.com>

On Thu, 30 Apr 2026 13:41:38 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> This patch introduces a new DAMON module (DAMON_HUGEPAGE)
> which collapses hot regions into huge pages.
> 
> DAMON_HUGEPAGE operates in the virtual memory space, for a
> specific task.

The new quota goal is for global memory, isn't it?  Why use global memory goal
for virtual address based scheme?

I understand it makes sense to monitor virtual address space for collapsing.
If we have to do collapsing, should we modify the quota goal to work for only
given task's virtual address space?

Also, what about split?  Should we also split huge pages into regular pages if
it is cold?  Maybe that could work on physical address space, and use the
proposed quota goal as is?

> The user is expected to supply the PID of
> the task that is going to be monitored through the
> monitored_pid module variable.
> 
> DAMON_HUGEPAGE uses the hugepage auto-tune mechanism to
> increase or decrease the aggressiveness of page collapsing.
> User autotuning is also available for additional tuning
> aggressiveness control.
> 
> The module also includes changes to the DAMON compilation,
> so that the module can be enabled or disabled.
> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> ---
>  mm/damon/Kconfig          |   7 +
>  mm/damon/Makefile         |   1 +
>  mm/damon/hugepage.c (new) | 341 ++++++++++++++++++++++++++++++++++++++

The cover letter was saying this module is for demonstrating the usage of the
new goal type, but this is not a sample module.  Let's make sure what is the
purpose of this module, and decide where to put it based on that.

I will skip detailed code review until the above high level question is
answered, as depending on the conclusion the code may be changed a lot.


Thanks,
SJ

[...]

  reply	other threads:[~2026-05-01  0:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 13:41 [RFC PATCH v1 0/4] mm/damon: Introduce a huge page collapsing mechanism using auto tuning gutierrez.asier
2026-04-30 13:41 ` [RFC PATCH v1 1/4] mm/damon: Generalize ctx_target creation for damon_ops_id and add vaddr support gutierrez.asier
2026-04-30 13:41 ` [RFC PATCH v1 2/4] mm/damon: Introduce DAMOS_QUOTA_HUGEPAGE auto tuning gutierrez.asier
2026-05-01  0:48   ` SeongJae Park
2026-04-30 13:41 ` [RFC PATCH v1 3/4] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing gutierrez.asier
2026-05-01  0:54   ` SeongJae Park [this message]
2026-04-30 13:41 ` [RFC PATCH v1 4/4] Documentation/admin-guide/mm/damon: add DAMON-based Hugepage Management documentation gutierrez.asier
2026-05-01  0:57   ` SeongJae Park
2026-05-01  0:41 ` [RFC PATCH v1 0/4] mm/damon: Introduce a huge page collapsing mechanism using auto tuning SeongJae Park
2026-05-04 13:52   ` Gutierrez Asier
2026-05-06 16:41     ` 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=20260501005458.79180-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