This patch introduces two new konbs for promotion/demotion:
`migrate_hot` and `migrate_cold`. It receives node ids for migration in
a comma-separated format as `<src,dst>`. The usage is as follows:

    # demote pages from nid 0 to nid 1
    $ echo 0,1 > /sys/module/mtier/parameters/migrate_cold
    # promote pages from nid 1 to nid 0
    $ echo 1,0 > /sys/module/mtier/parameters/migrate_hot

Susggested-by: Honggyu Kim <honggyu.kim@sk.com>
Signed-off-by: Yunjeong Mun <yunjeong.mun@sk.com>
---
 samples/damon/mtier.c | 68 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/samples/damon/mtier.c b/samples/damon/mtier.c
index ba6938a89c21..55d2edb84d7e 100644
--- a/samples/damon/mtier.c
+++ b/samples/damon/mtier.c
@@ -11,6 +11,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/string.h>
 
 static unsigned long node0_mem_used_bp __read_mostly = 9970;
 module_param(node0_mem_used_bp, ulong, 0600);
@@ -18,6 +19,32 @@ module_param(node0_mem_used_bp, ulong, 0600);
 static unsigned long node0_mem_free_bp __read_mostly = 50;
 module_param(node0_mem_free_bp, ulong, 0600);
 
+static int get_migrate_hot(
+		char *val, const struct kernel_param *kp);
+
+static const struct kernel_param_ops migrate_hot_ops = {
+	.set = param_set_charp,
+	.get = get_migrate_hot,
+};
+
+static char *migrate_hot __read_mostly = "";
+module_param_cb(migrate_hot, &migrate_hot_ops, &migrate_hot, 0600);
+MODULE_PARM_DESC(migrate_hot,
+	"Specify source and destination node id as a comma-seperated pair");
+
+static int get_migrate_cold(
+		char *val, const struct kernel_param *kp);
+
+static const struct kernel_param_ops migrate_cold_ops = {
+	.set = param_set_charp,
+	.get = get_migrate_cold,
+};
+
+static char *migrate_cold __read_mostly = "";
+module_param_cb(migrate_cold, &migrate_cold_ops, &migrate_cold, 0600);
+MODULE_PARM_DESC(migrate_cold,
+	"Specify source and destination node id as a comma-seperated pair");
+
 static int damon_sample_mtier_enable_store(
 		const char *val, const struct kernel_param *kp);
 
@@ -37,6 +64,30 @@ struct region_range {
 	phys_addr_t end;
 };
 
+static int parse_migrate_node(int *src, int *dst, bool promote) {
+	char *comma;
+	char buf[32];
+
+	if (promote)
+		strscpy(buf, migrate_hot, sizeof(buf));
+	else
+		strscpy(buf, migrate_cold, sizeof(buf));
+
+	comma = strchr(buf, ',');
+	if (!comma)
+		return -EINVAL;
+
+	*comma = '\0';
+	comma++;
+
+	if (kstrtoint(buf, 0, src))
+		return -EINVAL;
+	if (kstrtoint(comma, 0, dst))
+		return -EINVAL;
+
+	return 0;
+}
+
 static int numa_info_init(int target_node, struct region_range *range) {
 
 	if (!node_online(target_node)) {
@@ -64,6 +115,7 @@ static struct damon_ctx *damon_sample_mtier_build_ctx(bool promote)
 	struct damos_quota_goal *quota_goal;
 	struct damos_filter *filter;
 	struct region_range addr;
+	int src, dst;
 
 	ctx = damon_new_ctx();
 	if (!ctx)
@@ -94,8 +146,10 @@ static struct damon_ctx *damon_sample_mtier_build_ctx(bool promote)
 		goto free_out;
 	damon_add_target(ctx, target);
 
-	int ret = promote ? numa_info_init(1, &addr) : numa_info_init(0, &addr);
-	if (ret)
+	if (parse_migrate_node(&src, &dst, promote))
+		goto free_out;
+
+	if (numa_info_init(src, &addr))
 		goto free_out;
 
 	region = damon_new_region(addr.start, addr.end);
@@ -171,6 +225,16 @@ static void damon_sample_mtier_stop(void)
 	damon_destroy_ctx(ctxs[1]);
 }
 
+static int get_migrate_hot(char *buf, const struct kernel_param *kp)
+{
+       return scnprintf(buf, PAGE_SIZE, "%s", migrate_hot);
+}
+
+static int get_migrate_cold(char *buf, const struct kernel_param *kp)
+{
+       return scnprintf(buf, PAGE_SIZE, "%s", migrate_cold);
+}
+
 static int damon_sample_mtier_enable_store(
 		const char *val, const struct kernel_param *kp)
 {
-- 
2.34.1

Hello Yunjeong,

On Tue,  1 Jul 2025 17:54:17 +0900 Yunjeong Mun <yunjeong.mun@sk.com> wrote:

> This patch introduces two new konbs for promotion/demotion:
> `migrate_hot` and `migrate_cold`. It receives node ids for migration in
> a comma-separated format as `<src,dst>`. The usage is as follows:
> 
>     # demote pages from nid 0 to nid 1
>     $ echo 0,1 > /sys/module/mtier/parameters/migrate_cold
>     # promote pages from nid 1 to nid 0
>     $ echo 1,0 > /sys/module/mtier/parameters/migrate_hot

I understand you want to support some setups such as having a fast node of id 1
and a slow node of id 0.

Because mtier is a sample code, I think it's primary goal is to help developers
know how they can use DAMON API functions for writing kernel code that is
required for a situation similar to the sample.  Hence the sample should be
clean and simple enough to be understood.

The assumption of the two nodes (the fast node 0 and the slow node 1) is
arguably intended for making the code simple, in my opinion.  We could of
course make this kind of changes if it helps more experiments for understanding
the code, as sample code is not only for reading but also running.

> 
> Susggested-by: Honggyu Kim <honggyu.kim@sk.com>

checkpatch.pl found a typo: s/Susggest/Suggest/

> Signed-off-by: Yunjeong Mun <yunjeong.mun@sk.com>
> ---
>  samples/damon/mtier.c | 68 +++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 66 insertions(+), 2 deletions(-)

But, I feel like this change is rather making code too longer and complicated.
Hence I would suggest dropping this patch if you agree.  Please let me know if
you have different opinions, or I'm missing something.


Thanks,
SJ

[...]

Hello SeongJae,

On Tue,  1 Jul 2025 17:08:25 -0700 SeongJae Park <sj@kernel.org> wrote:
> Hello Yunjeong,
> 
> On Tue,  1 Jul 2025 17:54:17 +0900 Yunjeong Mun <yunjeong.mun@sk.com> wrote:
> 
> > This patch introduces two new konbs for promotion/demotion:
> > `migrate_hot` and `migrate_cold`. It receives node ids for migration in
> > a comma-separated format as `<src,dst>`. The usage is as follows:
> > 
> >     # demote pages from nid 0 to nid 1
> >     $ echo 0,1 > /sys/module/mtier/parameters/migrate_cold
> >     # promote pages from nid 1 to nid 0
> >     $ echo 1,0 > /sys/module/mtier/parameters/migrate_hot
> 
> I understand you want to support some setups such as having a fast node of id 1
> and a slow node of id 0.
> 
> Because mtier is a sample code, I think it's primary goal is to help developers
> know how they can use DAMON API functions for writing kernel code that is
> required for a situation similar to the sample.  Hence the sample should be
> clean and simple enough to be understood.

Thanks for explanation. I understand the intention of mtier module.
As you mentioned, mtier is helpful for leraning how to configure and 
run DAMON.

> 
> The assumption of the two nodes (the fast node 0 and the slow node 1) is
> arguably intended for making the code simple, in my opinion.  We could of
> course make this kind of changes if it helps more experiments for understanding
> the code, as sample code is not only for reading but also running.
> 

I also think that fast node 0 and the slow node 1 is intuitive and easy to
understand the code.

> > 
> > Susggested-by: Honggyu Kim <honggyu.kim@sk.com>
> 
> checkpatch.pl found a typo: s/Susggest/Suggest/
> 
> > Signed-off-by: Yunjeong Mun <yunjeong.mun@sk.com>
> > ---
> >  samples/damon/mtier.c | 68 +++++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 66 insertions(+), 2 deletions(-)
> 
> But, I feel like this change is rather making code too longer and complicated.
> Hence I would suggest dropping this patch if you agree.  Please let me know if
> you have different opinions, or I'm missing something.
> 

Ok, I will drop this patch in next version RFC. As you mentiond, mtier
module should be simple and intuitive enough. I will consider this
kind of tiering module to mm/damon. I'll send you RFC v2 soon.

Best Regards,
Yunjeong Mun

> 
> Thanks,
> SJ
> 
> [...]

On Thu,  3 Jul 2025 14:18:34 +0900 Yunjeong Mun <yunjeong.mun@sk.com> wrote:

> Hello SeongJae,
> 
> On Tue,  1 Jul 2025 17:08:25 -0700 SeongJae Park <sj@kernel.org> wrote:
> > Hello Yunjeong,
> > 
> > On Tue,  1 Jul 2025 17:54:17 +0900 Yunjeong Mun <yunjeong.mun@sk.com> wrote:
[...]
> > Because mtier is a sample code, I think it's primary goal is to help developers
> > know how they can use DAMON API functions for writing kernel code that is
> > required for a situation similar to the sample.  Hence the sample should be
> > clean and simple enough to be understood.
> 
> Thanks for explanation. I understand the intention of mtier module.
> As you mentioned, mtier is helpful for leraning how to configure and 
> run DAMON.

Glad to hear this sample is working for the intended goal!

[...]
> > But, I feel like this change is rather making code too longer and complicated.
> > Hence I would suggest dropping this patch if you agree.  Please let me know if
> > you have different opinions, or I'm missing something.
> > 
> 
> Ok, I will drop this patch in next version RFC. As you mentiond, mtier
> module should be simple and intuitive enough. I will consider this
> kind of tiering module to mm/damon. I'll send you RFC v2 soon.

Thank you for kindly accepting my suggestion.  Looking forward to the next
patches!


Thanks,
SJ

[...]