public inbox for linux-mm@kvack.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, ljs@kernel.org,
	Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org,
	surenb@google.com, mhocko@suse.com, corbet@lwn.net,
	skhan@linuxfoundation.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action
Date: Mon, 16 Mar 2026 17:32:05 -0700	[thread overview]
Message-ID: <20260317003206.89342-1-sj@kernel.org> (raw)
In-Reply-To: <20260316183805.2090297-1-gutierrez.asier@huawei-partners.com>

Hello Asier,

On Mon, 16 Mar 2026 18:38:05 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> This patch set introces a new action: DAMOS_COLLAPSE.
> 
> For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
> working, since it relies on hugepage_madvise to add a new slot. This
> slot should be picked up by khugepaged and eventually collapse (or
> not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
> enabled, khugepaged will not be working, and therefore no collapse
> will happen.
> 
> DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
> the address range synchronously.
> 
> This new action may be required to support autotuning with hugepage as
> a goal.

Above all makes sense.  Thank you for posting this patch.

Do you have some test results that you can also share together?  It would be
nice if it can demonstrate the benefit of DAMOS_COLLAPSE over DAMOS_HUGEPAGE.

> 
> [1] https://lore.kernel.org/lkml/20260314165156.86647-1-sj@kernel.org/

Seems the above link is just added by a mistake?  If not, please clarify.

> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> Reviewed-by: SeongJae Park <sj@kernel.org>
> ---
>  Documentation/mm/damon/design.rst | 4 ++++
>  include/linux/damon.h             | 1 +
>  mm/damon/sysfs-schemes.c          | 4 ++++
>  mm/damon/vaddr.c                  | 3 +++
>  4 files changed, 12 insertions(+)
[...]
> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index 3a441fbca170..6720dc70c487 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -140,6 +140,7 @@ enum damos_action {
>  	DAMOS_PAGEOUT,
>  	DAMOS_HUGEPAGE,
>  	DAMOS_NOHUGEPAGE,
> +	DAMOS_COLLAPSE,
>  	DAMOS_LRU_PRIO,
>  	DAMOS_LRU_DEPRIO,
>  	DAMOS_MIGRATE_HOT,

sashiko.dev adds [1] below comments.  Let me also add my comments in line.

: This isn't a bug, but should a kernel-doc entry for @DAMOS_COLLAPSE be added
: to the comment block above this enum?

Makes sense.  'make htmldocs' may complain otherwise.  Asier, could you please
add the kernel-doc comment for DAMOS_COLLAPSE in the next spin?

: 
: Also, does inserting DAMOS_COLLAPSE here shift the integer values of the
: subsequent enum entries like DAMOS_STAT?
: 
: The DAMON sysfs selftest script (tools/testing/selftests/damon/sysfs.py) uses
: a hardcoded dictionary action_val to map string names to their integer enum
: values.
: 
: If the enum values shift, the test's assertion:
: 
: assert_true(dump['action'] == action_val[scheme.action])
: 
: might fail when checking the struct memory via drgn. Could the python test
: dictionary be updated to reflect the new values, or could the new action be
: added at the end of the enum list?

There is no test that uses DAMOS actions that defined after DAMOS_NOHUGEPAGE,
so no real test will break.  But this is a good point.  It would be better to
update the hard-coded value together.  Asier, could you also update the
'action_val' dict of assert_scheme_committed() function in
tools/testing/selftets/damon/sysfs.py for the updated enum value in the next
version?

[1] https://sashiko.dev/#/patchset/20260316183805.2090297-1-gutierrez.asier@huawei-partners.com


Thanks,
SJ

[...]


  reply	other threads:[~2026-03-17  0:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16 18:38 [RFC PATCH v2 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action gutierrez.asier
2026-03-17  0:32 ` SeongJae Park [this message]
2026-03-17  6:52   ` Gutierrez Asier
2026-03-18  0:52     ` SeongJae Park
2026-03-18 14:41       ` Gutierrez Asier
  -- strict thread matches above, loose matches on Subject: below --
2026-03-23 14:56 [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE gutierrez.asier
2026-03-23 14:56 ` [RFC PATCH v2 1/1] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action gutierrez.asier

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=20260317003206.89342-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=artem.kuzin@huawei.com \
    --cc=corbet@lwn.net \
    --cc=damon@lists.linux.dev \
    --cc=gutierrez.asier@huawei-partners.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=stepanov.anatoly@huawei.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --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