Re: [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning

Re: [PATCH v1 0/3] mm/damon: Introduce a huge page collapsing mechanism using auto tuning

[SeongJae Park]

On Tue, 16 Jun 2026 15:03:13 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> Overview
> ========
> 
> This patch set introduces a new autotuning which allows to collapse
> hot regions into hugepages.
> 
> Motivation
> ==========
> 
> Since TLB is a bottleneck for many systems[1], a way to optimize TLB
> misses (or hits) is to use huge pages. Unfortunately, using "always"
> in THP leads to memory fragmentation and memory waste. For this reason,
> most application guides and system administrators suggest to disable THP.
> 
> Currently DAMON has DAMOS_HUGEPAGE, DAMOS_NONHUGEPAGE and DAMOS_COLLAPSE.
> However, there is no way to tune the settings. It will collapse all the
> hot regions that meet the access pattern. If the server is a bare metal
> database or big data server, this will also lead to eventual fragmentation.
> 
> Additionally, currently THP is set globally. Ideally, there should be a
> way to control which tasks can use huge pages.

Could you please reword for prctl(PR_SET_THP_DISABLE) like per-process control
cases, as we discussed [1] on RFC v3?

> 
> Solution
> ========
> 
> DAMON has now a way to autotune some of the variables and adjust quotas
> automatically, so that DAMON is fired only under the right circumstances.
> It would be nice to have something similar, but for huge pages.
> 
> A new autotuning quota goal[2], damos_hugepage_mem_bp, is introduced,
> which checks the huge page consumption to total memory consumption. This
> new quota mechanism reuses current autotuning architecture.
> 
> A new sample module (SAMPLE_DAMON_HPAGE) is introduced to demonstrate
> the use of huge pages collapse autotuning. The goal is to collapse hot
> regions of a given process into huge pages. The sample module launches
> a kdamond thread for a certain task provided by the user through
> taget_pid module argument. Hugepage goal autotuning will automatically
> adjust the aggressiveness of hot region collapses.
> 
> This sample module also has a user autotuning knob which allows the
> user to adjust the aggressiveness of page collapsing.
> 
> Benchmarks
> ==========
> 
> Huge page collapse autotuning was tested in a physicial machine with
> MariaDB 10.5.29 and sysbench as the benchmark framework.
> 
> The hugepage module was set up in the following way:
> 
> # echo 1000 > min_age
> # echo 1000 > quota_percentage_hugepage

I guess this is the quota goal?  What is the unit?  I guess it is aparently not
percentage?  The name doesn't sound like very consistent or intuitive.  How
about hugepage_mem_bp or target_hugepage_mem_bp?

> # echo $(pidof mariadbd) > taget_pid
> # echo on > enabled
> 
> The goal was to achieve 5% of the total memory used as hugepage.

I guess this is what the above example is setting using
'quotta_percentage_hugepage'?  If so, it means the unit is 1/20000 ?  Is this
correct...?

> Since the database was not very big, we may not be able to achieve
> high amount of huge pages per total memory consumption ratio.

I believe this patch series will work as you explained.  But, it seems bit
weird to show a test result that doesn't demonstrate what this patch is aimed
to achive.  Could you increase the size of the database?  IIRC, you were able
to show the percentage is over-achived case in an early version.

> 
> The table below shows the memory consumption over time. Timestamp is in
> second and the memory usage in is MBytes. Gaps in the timestamp means
> that no changes in the hugepage consumption happened over that period
> of time in MB. The total used memory is calculated as
> mem_total - mem free. The huge page used is calculated as
> huge_page_anon + huge_page_shmem + huge_page_file. The table also
> shows the huge pages to total memory ratio.
> 
> Hugepage autotune benchmark:
> +-----------+----------------+----------------+----------------------+
> | timestamp | total mem used | huge page used | percentage hugepage  |
> +-----------+----------------+----------------+----------------------+
> | 0         | 3044.988281    | 0              | 0%                   |
> | 22        | 3160.207031    | 2              | 0.06%                |
> | 30        | 3250.90625     | 4              | 0.12%                |
> | 69        | 3781.238281    | 6              | 0.16%                |
> | 71        | 3822.226563    | 8              | 0.21%                |
> | 72        | 3846.578125    | 10             | 0.26%                |
> | 73        | 3852.402344    | 12             | 0.31%                |
> | 74        | 3868           | 14             | 0.36%                |
> | 75        | 3881.84375     | 104            | 2.68%                |
> | 275       | 4194.175781    | 106            | 2.52%                |
> +-----------+----------------+----------------+----------------------+
> After second 275, no more pages are collapsed into hugepages
> 
> 
> THP (always) benchmark:
> +-----------+----------------+----------------+---------------------+
> | timestamp | total mem used | huge page used | percentage hugepage |
> +-----------+----------------+----------------+---------------------+
> |         1 |    4489.320313 |            184 |         4.098615986 |
> |        15 |    4581.871094 |            214 |         4.670580984 |
> |        30 |    4757.742188 |            376 |         7.902908253 |
> |        45 |    4937.574219 |            558 |         11.30109595 |
> |        60 |    5147.867188 |            728 |         14.14177898 |
> |        75 |      5407.0625 |            918 |         16.97779524 |
> |        95 |    5668.796875 |           1040 |         18.34604455 |
> |       105 |    5723.839844 |           1056 |         18.44915352 |
> |       115 |     5736.84375 |           1072 |         18.68623317 |
> |       125 |    5732.042969 |           1088 |         18.98101612 |
> |       186 |    5753.601563 |           1184 |         20.57841488 |
> |       246 |    5746.398438 |           1280 |         22.27482159 |
> |       306 |    5752.128906 |           1376 |         23.92157795 |
> |       367 |      5772.5625 |           1472 |         25.49994045 |
> |       427 |    5832.019531 |           1568 |         26.88605536 |
> |       488 |    5813.246094 |           1664 |         28.62428277 |
> |       548 |    5807.621094 |           1760 |         30.30500736 |
> |       598 |    5841.253906 |           1822 |         31.19193292 |
> |       669 |    5982.160156 |           1854 |         30.99214918 |
> |       931 |    5946.605469 |           1868 |         31.41287933 |
> |       981 |    6020.207031 |           1896 |         31.49393352 |
> |       991 |    5988.445313 |           1910 |         31.89475566 |
> |      1011 |    5988.570313 |           1926 |         32.16126554 |
> |      1032 |    6016.039063 |           1936 |         32.18064211 |
> |      1575 |    6057.289063 |           1968 |         32.48978181 |
> |      1606 |    6026.167969 |           2000 |         33.18858702 |
> +-----------+----------------+----------------+---------------------+
> I ignored some points to make the table shorter. Anyway, the amount
> of memory consumption, total and huge pages, is a lot higher than
> with DAMON hugepage autotuning.

Could you further clarify why it is, and what this means?

> 
> 
> Performance:
> Baseline (no THP, module off) -> 18,162.45 transactions per second
> Hugepage autotune -> 18,211.82 transactions per second (+0.27% improvement)
> THP always -> 18,388.3 (+1.24%)
> THP madvise -> 18,179.25 (+0.09%)
> 
> Improvement is due to lower TLB misses

So this result says THP always is much better than the Hugepage autotune in
terms of the performance.  Maybe you want to claim Hugepage autotune is better
in terms of the memory efficiency?  Could you please clarify further?

> 
> Patches Sequence
> ================
> Patch 1 -> Introduce DAMOS_QUOTA_HUGEPAGE_MEM_BP and autotuning
> Patch 2 -> Module that demonstrates how to use
>            DAMOS_QUOTA_HUGEPAGE_MEM_BP and DAMOS_QUOTA_GOAL_TUNER_TEMPORAL
> Patch 3 -> Support for DAMOS_QUOTA_HUGEPAGE_MEM_BP in sysfs-schemes
> 
> Changes from previous versions
> ==============================
> RFC 4[3] -> v1
>   - Renamed config to SAMPLE_DAMON_HPAGE, file to hpage.c and
>     functions to damon_sample_hpage_...
>   - Make the module depend on TRANSPARENT_HUGEPAGE, since
>     the module will need some THP functions anyway
>   - Removed documentation, since this is just a sample module
>   - Removed DAMOS_QUOTA_HUGEPAGE_MEM_BP from
>     damos_sysfs_add_quota_score
>   - Added a short description of the module in Kconfig

Thank you for continuing this work!

[...]

> [1] https://dl.acm.org/doi/pdf/10.1145/3307650.3322227
> [2] https://lore.kernel.org/e67f05ad-dbb9-45e6-ba30-b167a99ac67d@huawei-partners.com
> [3] https://lore.kernel.org/20260611150244.3454699-1-gutierrez.asier@huawei-partners.com
> [4] https://lore.kernel.org/20260604150338.501128-1-gutierrez.asier@huawei-partners.com
> [5] https://lore.kernel.org/20260522145518.158910-1-gutierrez.asier@huawei-partners.com
> [6] https://lore.kernel.org/20260522171210.900B11F00A3D@smtp.kernel.org
> [7] https://lore.kernel.org/20260522171633.AAF5B1F000E9@smtp.kernel.org
> [8] https://lore.kernel.org/20260430134139.2446417-1-gutierrez.asier@huawei-partners.com
> [9] https://lore.kernel.org/all/20260430154338.E22E6C2BCB3@smtp.kernel.org/

[1] https://lore.kernel.org/9f9e2159-5a6b-496f-9633-fa06c0217948@huawei-partners.com


Thanks,
SJ

[...]

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:

> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> 
> This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> which collapses hot regions into huge pages.
> 
> SAMPLE_DAMON_HPAGE operates in the virtual memory space, for a
> specific task. The user is expected to supply the PID of the task
> that is going to be monitored through the target_pid module
> variable.

s/variable/parameter/ ?

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

Is the user autotuning really needed for this sample module?  I'm concerned if
it is unnecessarily making the code complicated.  Can we drop this?

> 
> The module also includes changes to the DAMON compilation,

I think this is not true?

> so that
> the module can be enabled or disabled.
> 
> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> ---
>  samples/damon/Kconfig       |  14 +++
>  samples/damon/Makefile      |   1 +
>  samples/damon/hpage.c (new) | 207 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 222 insertions(+)
> 
> diff --git a/samples/damon/Kconfig b/samples/damon/Kconfig
> index cbf96fd8a8bf..1ef0b12c32e6 100644
> --- a/samples/damon/Kconfig
> +++ b/samples/damon/Kconfig
> @@ -40,4 +40,18 @@ config SAMPLE_DAMON_MTIER
>  
>  	  If unsure, say N.
>  
> +config SAMPLE_DAMON_HPAGE
> +	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HPAGE)"

Please make this be consistent to other sample modules.  E.g., DAMON sample
module for ...

> +	depends on DAMON && DAMON_VADDR && TRANSPARENT_HUGEPAGE
> +	help
> +	  This builds DAMON sample module for collapsing regions into huge pages.

... for huge pages collapsing?

> +
> +	  This module monitors a certain PID provided by the user through
> +	  target_pid attribute. Hot regions are determined by DAMON-based

Please use two spaces between sentences, consistent to others.

> +	  sampling. Collapsing occurs according to the quota goal using total

"DAMON-based sampling" sounds verbose and technically not making much sense.
How about just "DAMON"?

> +	  memory usage to huge page usage ratio. The ratio is set by the user

huge page to total memory usage ratio?

> +	  through a module attribute.

s/attribute/parameter/ ?

> +
> +	  If unsure, say N.
> +
>  endmenu
> diff --git a/samples/damon/Makefile b/samples/damon/Makefile
> index 72f68cbf422a..a348dc74ddcb 100644
> --- a/samples/damon/Makefile
> +++ b/samples/damon/Makefile
> @@ -3,3 +3,4 @@
>  obj-$(CONFIG_SAMPLE_DAMON_WSSE) += wsse.o
>  obj-$(CONFIG_SAMPLE_DAMON_PRCL) += prcl.o
>  obj-$(CONFIG_SAMPLE_DAMON_MTIER) += mtier.o
> +obj-$(CONFIG_SAMPLE_DAMON_HUGEPAGE) += hpage.o

... Can this be compiled...?

> diff --git a/samples/damon/hpage.c b/samples/damon/hpage.c
> new file mode 100644
> index 000000000000..ebbe5e1be1a1
> --- /dev/null
> +++ b/samples/damon/hpage.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026 HUAWEI, Inc.
> + *             https://www.huawei.com
> + *
> + * Author: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> + */
> +
> +#define pr_fmt(fmt) "damon_sample_hpage: " fmt
> +
> +#include <linux/damon.h>
> +#include <linux/kstrtox.h>
> +#include <linux/module.h>
> +
> +#ifdef MODULE_PARAM_PREFIX
> +#undef MODULE_PARAM_PREFIX
> +#endif
> +#define MODULE_PARAM_PREFIX "damon_sample_hpage."
> +
> +static bool enabled __read_mostly;
> +
> +static unsigned long target_pid;
> +module_param(target_pid, ulong, 0600);

Why 'ulong'?  I think 'int' is enough?

> +
> +/* By default, total huge pages to system memory usage ratio set to 10% */
> +static unsigned long quota_percentage_hugepage __read_mostly = 1000;
> +module_param(quota_percentage_hugepage, ulong, 0600);

"percentage" in the name sounds weird.  What about hugepage_mem_bp or
target_hugepage_mem_bp?

> +
> +static unsigned long quota_autotune_feedback __read_mostly;
> +module_param(quota_autotune_feedback, ulong, 0600);

I'm not really sure if this is really needed.  If not, could we drop this?

> +
> +static struct damon_ctx *ctx;
> +static struct pid *target_pidp;
> +
> +static int damon_sample_hpage_damon_call_fn(void *data)
> +{
> +	struct damon_ctx *c = data;
> +	struct damon_target *t;
> +
> +	damon_for_each_target(t, c) {
> +		struct damon_region *r;
> +		unsigned long hugepages = 0;
> +
> +		damon_for_each_region(r, t) {
> +			if (r->nr_accesses > 0)
> +				hugepages += r->ar.end - r->ar.start;
> +		}
> +		hugepages = hugepages / HPAGE_PMD_SIZE;
> +		pr_info("hugepage: %lu\n", hugepages);
> +	}
> +	return 0;
> +}

What's the purpose of this function?  If not really  needed, can we drop?

> +
> +static struct damon_call_control call_control = {
> +	.fn = damon_sample_hpage_damon_call_fn,
> +	.repeat = true,
> +};
> +
> +static int damon_sample_hpage_start(void)
> +{
> +	int err;
> +	struct damon_target *target;
> +	struct damos *scheme;
> +	struct damos_quota_goal *goal;
> +
> +	pr_info("start\n");
> +
> +

Let's have only one blank line.

> +	ctx = damon_new_ctx();
> +	if (!ctx)
> +		return -ENOMEM;
> +	if (damon_select_ops(ctx, DAMON_OPS_VADDR)) {
> +		damon_destroy_ctx(ctx);
> +		return -EINVAL;
> +	}
> +
> +	target = damon_new_target();
> +	if (!target) {
> +		damon_destroy_ctx(ctx);
> +		return -ENOMEM;
> +	}
> +	damon_add_target(ctx, target);
> +	target_pidp = find_get_pid(target_pid);
> +	if (!target_pidp) {
> +		damon_destroy_ctx(ctx);
> +		return -EINVAL;
> +	}
> +	target->pid = target_pidp;
> +
> +	scheme = damon_new_scheme(&(struct damos_access_pattern) {
> +				.min_sz_region = HPAGE_PMD_SIZE,
> +				.max_sz_region = ULONG_MAX,
> +				.min_nr_accesses = 0,
> +				.max_nr_accesses = UINT_MAX,
> +				.min_age_region = 50,
> +				.max_age_region = UINT_MAX},
> +				DAMOS_COLLAPSE, 0,
> +				&(struct damos_quota) {
> +				.ms = 10,

I don't really suggest time quota to people nowadays.  Size quota is easier to
understand and sufficient in many cases in my humble opinion.  Did you find it
is really helpful and essential for this module?  If not, could we unset time
quota?

> +				.sz = 128 * 1024 * 1024,
> +				.reset_interval = 1000,
> +				.weight_sz = 0,
> +				.weight_nr_accesses = 1,
> +				.weight_age = 1,
> +				.goal_tuner = DAMOS_QUOTA_GOAL_TUNER_TEMPORAL},
> +				&(struct damos_watermarks){}, NUMA_NO_NODE);
> +	if (!scheme) {
> +		damon_destroy_ctx(ctx);
> +		return -ENOMEM;
> +	}
> +	damon_set_schemes(ctx, &scheme, 1);
> +	goal = damos_new_quota_goal(DAMOS_QUOTA_HUGEPAGE_MEM_BP,
> +				quota_percentage_hugepage);
> +	if (!goal) {
> +		damon_destroy_ctx(ctx);
> +		return -ENOMEM;
> +	}
> +	damos_add_quota_goal(&scheme->quota, goal);
> +
> +	if (quota_autotune_feedback) {
> +		goal = damos_new_quota_goal(DAMOS_QUOTA_USER_INPUT, 10000);
> +		if (!goal) {
> +			damon_destroy_ctx(ctx);
> +			return -ENOMEM;
> +		}
> +		goal->current_value = quota_autotune_feedback;
> +		damos_add_quota_goal(&scheme->quota, goal);
> +	}

Seems this module is not really utilizing the user input feedback.  To use that
in real, the module should periodically read user's input and feed that to
DAMON core.  I find no code doing that in this module.  If it is not really
being used, I'd suggest to drop this.

> +
> +	err = damon_start(&ctx, 1, true);
> +	if (err) {
> +		damon_destroy_ctx(ctx);
> +		return err;
> +	}
> +
> +	call_control.data = ctx;
> +	err = damon_call(ctx, &call_control);
> +	if (err) {
> +		damon_stop(&ctx, 1);
> +		damon_destroy_ctx(ctx);
> +	}
> +	return err;
> +}
> +
> +static void damon_sample_hpage_stop(void)
> +{
> +	pr_info("stop\n");
> +	if (ctx) {
> +		damon_stop(&ctx, 1);
> +		damon_destroy_ctx(ctx);
> +	}
> +}
> +static int damon_sample_hpage_enabled_store(const char *val,
> +				const struct kernel_param *kp)
> +{
> +	bool is_enabled = enabled;
> +	int err;
> +
> +	err = kstrtobool(val, &enabled);
> +	if (err)
> +		return err;
> +
> +	if (enabled == is_enabled)
> +		return 0;
> +
> +	if (!damon_initialized())
> +		return 0;
> +
> +	if (enabled) {
> +		err = damon_sample_hpage_start();
> +		if (err)
> +			enabled = false;
> +		return err;
> +	}
> +	damon_sample_hpage_stop();
> +	return 0;
> +}
> +
> +static const struct kernel_param_ops enabled_param_ops = {
> +	.set = damon_sample_hpage_enabled_store,
> +	.get = param_get_bool,
> +};
> +
> +module_param_cb(enabled, &enabled_param_ops, &enabled, 0600);
> +MODULE_PARM_DESC(enabled,
> +	"Enable or disable DAMON_HUGEPAGE (default: disabled)");

s/DAMON_HUGEPAGE/DAMON_SAMPLE_HPAGE/ ?

"(default: disabled)" seems unnecessary.  Could you please remove that?

> +
> +static int __init damon_sample_hpage_init(void)
> +{
> +	int err = 0;
> +
> +	if (!damon_initialized()) {
> +		if (enabled)
> +			enabled = false;
> +		pr_warn("Module not initialized\n");
> +		return -ENOMEM;
> +	}
> +
> +	if (enabled) {
> +		err = damon_sample_hpage_start();
> +		if (err)
> +			enabled = false;
> +	}
> +	return err;
> +}
> +
> +module_init(damon_sample_hpage_init);
> -- 
> 2.43.0


Thanks,
SJ

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> 
> > From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> > 
> > This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> > which collapses hot regions into huge pages.

As I mentioned on the previous version of this series, this sample module looks
much better than the initial shape to my humble eyes.  Much smaller and
simpler.  I really appreciate Asier's efforts on making this.

However... I was asking myself if this module is really needed last night, and
still got not real good and confident answer.

After all, this is a sample module.  The purpose is to show sample code thhat
helps people understanding how they can use DAMON API.  Maybe we can argue this
module can be helpful at understanding how DAMOS quota goal can be used.  But,
mtier is already showing that.  So I cannot say what new advantage this module
is really bringing.

Meanwhile, this patch adds ~200 lines of code.  It is a very small and simple
sample module, but still we should maintain it.  I, to be honest, getting
little bit concerned about the maintenance overhead now.

So, if Asier has a good reason to add this module that I'm missing, I'd like to
humbly ask to consider dropping of this module for now.  I'm so sorry for
raising this concern this late.  But, Asier, may I ask what do you think?


Thanks,
SJ

[...]

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Wed, 17 Jun 2026 17:16:20 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> > On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> > 
> > > From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> > > 
> > > This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> > > which collapses hot regions into huge pages.
> 
> As I mentioned on the previous version of this series, this sample module looks
> much better than the initial shape to my humble eyes.  Much smaller and
> simpler.  I really appreciate Asier's efforts on making this.
> 
> However... I was asking myself if this module is really needed last night, and
> still got not real good and confident answer.
> 
> After all, this is a sample module.  The purpose is to show sample code thhat
> helps people understanding how they can use DAMON API.  Maybe we can argue this
> module can be helpful at understanding how DAMOS quota goal can be used.  But,
> mtier is already showing that.  So I cannot say what new advantage this module
> is really bringing.
> 
> Meanwhile, this patch adds ~200 lines of code.  It is a very small and simple
> sample module, but still we should maintain it.  I, to be honest, getting
> little bit concerned about the maintenance overhead now.
> 
> So, if Asier has a good reason to add this module that I'm missing, I'd like to

s/if/unless/

Sorry.

> humbly ask to consider dropping of this module for now.  I'm so sorry for
> raising this concern this late.  But, Asier, may I ask what do you think?
> 
> 
> Thanks,
> SJ
> 
> [...]


Thanks,
SJ

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[Gutierrez Asier]

Hi SJ,

On 6/18/2026 3:16 AM, SeongJae Park wrote:
> On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
>> On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:
>>
>>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>>
>>> This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
>>> which collapses hot regions into huge pages.
> 
> As I mentioned on the previous version of this series, this sample module looks
> much better than the initial shape to my humble eyes.  Much smaller and
> simpler.  I really appreciate Asier's efforts on making this.
> 
> However... I was asking myself if this module is really needed last night, and
> still got not real good and confident answer.
> 
> After all, this is a sample module.  The purpose is to show sample code thhat
> helps people understanding how they can use DAMON API.  Maybe we can argue this
> module can be helpful at understanding how DAMOS quota goal can be used.  But,
> mtier is already showing that.  So I cannot say what new advantage this module
> is really bringing.
You are right, the main goal was to show how this quota goal can be used. 
> Meanwhile, this patch adds ~200 lines of code.  It is a very small and simple
> sample module, but still we should maintain it.  I, to be honest, getting
> little bit concerned about the maintenance overhead now.
I understand your concerns. I know code need maintenance, and DAMON is already
growing significantly.
> So, if Asier has a good reason to add this module that I'm missing, I'd like to
> humbly ask to consider dropping of this module for now.  I'm so sorry for
> raising this concern this late.  But, Asier, may I ask what do you think?
So, are you suggesting to drop the module and upstreaming only the DAMOS quota
goal stuff?> 
> Thanks,
> SJ
> 
> [...]
> 

-- 
Asier Gutierrez
Huawei

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Thu, 18 Jun 2026 14:51:42 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> Hi SJ,
> 
> On 6/18/2026 3:16 AM, SeongJae Park wrote:
> > On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <sj@kernel.org> wrote:
> > 
> >> On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> >>
> >>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >>>
> >>> This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> >>> which collapses hot regions into huge pages.
> > 
> > As I mentioned on the previous version of this series, this sample module looks
> > much better than the initial shape to my humble eyes.  Much smaller and
> > simpler.  I really appreciate Asier's efforts on making this.
> > 
> > However... I was asking myself if this module is really needed last night, and
> > still got not real good and confident answer.
> > 
> > After all, this is a sample module.  The purpose is to show sample code thhat
> > helps people understanding how they can use DAMON API.  Maybe we can argue this
> > module can be helpful at understanding how DAMOS quota goal can be used.  But,
> > mtier is already showing that.  So I cannot say what new advantage this module
> > is really bringing.
> You are right, the main goal was to show how this quota goal can be used. 
> > Meanwhile, this patch adds ~200 lines of code.  It is a very small and simple
> > sample module, but still we should maintain it.  I, to be honest, getting
> > little bit concerned about the maintenance overhead now.
> I understand your concerns. I know code need maintenance, and DAMON is already
> growing significantly.
> > So, if Asier has a good reason to add this module that I'm missing, I'd like to
> > humbly ask to consider dropping of this module for now.  I'm so sorry for
> > raising this concern this late.  But, Asier, may I ask what do you think?
> So, are you suggesting to drop the module and upstreaming only the DAMOS quota
> goal stuff?> 

Yes, if you don't mind.


Thanks,
SJ

[...]

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[Gutierrez Asier]

On 6/18/2026 5:57 PM, SeongJae Park wrote:
> On Thu, 18 Jun 2026 14:51:42 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
> 
>> Hi SJ,
>>
>> On 6/18/2026 3:16 AM, SeongJae Park wrote:
>>> On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <sj@kernel.org> wrote:
>>>
>>>> On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:
>>>>
>>>>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>>>>
>>>>> This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
>>>>> which collapses hot regions into huge pages.
>>>
>>> As I mentioned on the previous version of this series, this sample module looks
>>> much better than the initial shape to my humble eyes.  Much smaller and
>>> simpler.  I really appreciate Asier's efforts on making this.
>>>
>>> However... I was asking myself if this module is really needed last night, and
>>> still got not real good and confident answer.
>>>
>>> After all, this is a sample module.  The purpose is to show sample code thhat
>>> helps people understanding how they can use DAMON API.  Maybe we can argue this
>>> module can be helpful at understanding how DAMOS quota goal can be used.  But,
>>> mtier is already showing that.  So I cannot say what new advantage this module
>>> is really bringing.
>> You are right, the main goal was to show how this quota goal can be used. 
>>> Meanwhile, this patch adds ~200 lines of code.  It is a very small and simple
>>> sample module, but still we should maintain it.  I, to be honest, getting
>>> little bit concerned about the maintenance overhead now.
>> I understand your concerns. I know code need maintenance, and DAMON is already
>> growing significantly.
>>> So, if Asier has a good reason to add this module that I'm missing, I'd like to
>>> humbly ask to consider dropping of this module for now.  I'm so sorry for
>>> raising this concern this late.  But, Asier, may I ask what do you think?
>> So, are you suggesting to drop the module and upstreaming only the DAMOS quota
>> goal stuff?> 
> 
> Yes, if you don't mind.
Sure. I will do it a bit later.

Thanks a lot for your help reviewing the code so far.
> 
> Thanks,
> SJ
> 
> [...]
> 

-- 
Asier Gutierrez
Huawei

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Thu, 18 Jun 2026 17:59:36 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:

> 
> 
> On 6/18/2026 5:57 PM, SeongJae Park wrote:
> > On Thu, 18 Jun 2026 14:51:42 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
> > 
> >> Hi SJ,
> >>
> >> On 6/18/2026 3:16 AM, SeongJae Park wrote:
> >>> On Tue, 16 Jun 2026 21:04:52 -0700 SeongJae Park <sj@kernel.org> wrote:
> >>>
> >>>> On Tue, 16 Jun 2026 15:03:15 +0000 <gutierrez.asier@huawei-partners.com> wrote:
> >>>>
> >>>>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
> >>>>>
> >>>>> This patch introduces a new DAMON module (SAMPLE_DAMON_HPAGE)
> >>>>> which collapses hot regions into huge pages.
> >>>
> >>> As I mentioned on the previous version of this series, this sample module looks
> >>> much better than the initial shape to my humble eyes.  Much smaller and
> >>> simpler.  I really appreciate Asier's efforts on making this.
> >>>
> >>> However... I was asking myself if this module is really needed last night, and
> >>> still got not real good and confident answer.
> >>>
> >>> After all, this is a sample module.  The purpose is to show sample code thhat
> >>> helps people understanding how they can use DAMON API.  Maybe we can argue this
> >>> module can be helpful at understanding how DAMOS quota goal can be used.  But,
> >>> mtier is already showing that.  So I cannot say what new advantage this module
> >>> is really bringing.
> >> You are right, the main goal was to show how this quota goal can be used. 
> >>> Meanwhile, this patch adds ~200 lines of code.  It is a very small and simple
> >>> sample module, but still we should maintain it.  I, to be honest, getting
> >>> little bit concerned about the maintenance overhead now.
> >> I understand your concerns. I know code need maintenance, and DAMON is already
> >> growing significantly.
> >>> So, if Asier has a good reason to add this module that I'm missing, I'd like to
> >>> humbly ask to consider dropping of this module for now.  I'm so sorry for
> >>> raising this concern this late.  But, Asier, may I ask what do you think?
> >> So, are you suggesting to drop the module and upstreaming only the DAMOS quota
> >> goal stuff?> 
> > 
> > Yes, if you don't mind.
> Sure. I will do it a bit later.

Thank you for kindly accepting my humble suggestion, Asier!

> 
> Thanks a lot for your help reviewing the code so far.

I sincerely appreciate your contributions, too.


Thanks,
SJ

[...]

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[Julian Braha]

Hi Asier,

On 6/16/26 16:03, gutierrez.asier@huawei-partners.com wrote:

> +config SAMPLE_DAMON_HPAGE
> +	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HPAGE)"
> +	depends on DAMON && DAMON_VADDR && TRANSPARENT_HUGEPAGE
The dependency on DAMON is unnecessary because you already depend on
DAMON_VADDR.

- Julian Braha

Re: [PATCH v1 2/3] mm/damon: introduce DAMON_HUGEPAGE for hot region hugepage collapsing

[SeongJae Park]

On Wed, 17 Jun 2026 17:12:45 +0100 Julian Braha <julianbraha@gmail.com> wrote:

> Hi Asier,
> 
> On 6/16/26 16:03, gutierrez.asier@huawei-partners.com wrote:
> 
> > +config SAMPLE_DAMON_HPAGE
> > +	bool "Build DAMON-based collapse of hot regions (SAMPLE_DAMON_HPAGE)"
> > +	depends on DAMON && DAMON_VADDR && TRANSPARENT_HUGEPAGE
> The dependency on DAMON is unnecessary because you already depend on
> DAMON_VADDR.

Nice findiing!  There are similar duplicated conditions for other sample
modules, too.  If anyone willing to, please feel free to post patches for
cleaning those out.


Thanks,
SJ

[...]