[PATCH 0/2] mm/damon: export symbols and introduce prdm module

[PATCH 0/2] mm/damon: export symbols and introduce prdm module

[Enze Li]

This patchset makes DAMON's advanced memory management accessible to a
broader range of users through two complementary enhancements.  First,
it exports the necessary DAMON core symbols to enable building loadable
kernel modules.  Building on this foundation, it then introduces the
'prdm' module, which extends the concept from the DAMON sample code
(prcl.c) into a production-ready, user-friendly tool.

The key strength of this module is its out-of-the-box simplicity: by
simply specifying the PIDs of target processes and enabling the module,
users can concurrently monitor memory access patterns across multiple
processes and trigger proactive reclamation automatically.  This
significantly lowers the barrier to using DAMON, allowing system
administrators and regular users without deep kernel expertise to easily
apply sophisticated memory optimization.

The goal is to help alleviate system-wide memory pressure and improve
performance for various workloads, advancing DAMON from a
developer-centric tool towards a practical solution for a wider
audience.

To test this 'prdm' module, you can follow these steps,

  # modprobe prdm
  # cd /sys/module/prdm/parameters
  # echo <target1_pid> > damon_prdm.target_pid
  # echo <target2_pid> > damon_prdm.target_pid
  # echo <target3_pid> > damon_prdm.target_pid
  # cat damon_prdm.target_pid
  Tasks: <target1_pid> <target2_pid> <target3_pid>(exited)
  # echo Y > damon_prdm.enabled

To stop the monitoring,

  # echo N > damon_prdm.enabled
  # rmmod prdm

Enze Li (2):
  mm/damon/core: export necessary symbols
  mm/damon/modules: introduce prdm module for DAMON

 mm/damon/Kconfig          |   2 +
 mm/damon/Makefile         |   1 +
 mm/damon/core.c           |  10 ++
 mm/damon/modules/Kconfig  |  18 +++
 mm/damon/modules/Makefile |   3 +
 mm/damon/modules/prdm.c   | 251 ++++++++++++++++++++++++++++++++++++++
 6 files changed, 285 insertions(+)
 create mode 100644 mm/damon/modules/Kconfig
 create mode 100644 mm/damon/modules/Makefile
 create mode 100644 mm/damon/modules/prdm.c


base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
-- 
2.52.0

[PATCH 1/2] mm/damon/core: export necessary symbols

[Enze Li]

This patch exports necessary DAMON core symbols to allow building
loadable kernel modules that leverage DAMON's monitoring capabilities
for advanced memory management techniques, such as proactive
reclamation.

The exported functions include those for context creation/destruction,
target and scheme management, and monitoring control.  This enables
external modules to create dedicated DAMON contexts and targets,
operation schemes, and control the monitoring lifecycle without
requiring direct modifications to the core DAMON subsystem.

Signed-off-by: Enze Li <lienze@kylinos.cn>
---
 mm/damon/core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index f9fc0375890a..b3f6b36a034d 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -108,6 +108,7 @@ int damon_select_ops(struct damon_ctx *ctx, enum damon_ops_id id)
 	mutex_unlock(&damon_ops_lock);
 	return err;
 }
+EXPORT_SYMBOL_GPL(damon_select_ops);
 
 /*
  * Construct a damon_region struct
@@ -409,6 +410,7 @@ struct damos *damon_new_scheme(struct damos_access_pattern *pattern,
 
 	return scheme;
 }
+EXPORT_SYMBOL_GPL(damon_new_scheme);
 
 static void damos_set_next_apply_sis(struct damos *s, struct damon_ctx *ctx)
 {
@@ -478,11 +480,13 @@ struct damon_target *damon_new_target(void)
 
 	return t;
 }
+EXPORT_SYMBOL_GPL(damon_new_target);
 
 void damon_add_target(struct damon_ctx *ctx, struct damon_target *t)
 {
 	list_add_tail(&t->list, &ctx->adaptive_targets);
 }
+EXPORT_SYMBOL_GPL(damon_add_target);
 
 bool damon_targets_empty(struct damon_ctx *ctx)
 {
@@ -553,6 +557,7 @@ struct damon_ctx *damon_new_ctx(void)
 
 	return ctx;
 }
+EXPORT_SYMBOL_GPL(damon_new_ctx);
 
 static void damon_destroy_targets(struct damon_ctx *ctx)
 {
@@ -573,6 +578,7 @@ void damon_destroy_ctx(struct damon_ctx *ctx)
 
 	kfree(ctx);
 }
+EXPORT_SYMBOL_GPL(damon_destroy_ctx);
 
 static bool damon_attrs_equals(const struct damon_attrs *attrs1,
 		const struct damon_attrs *attrs2)
@@ -763,6 +769,7 @@ void damon_set_schemes(struct damon_ctx *ctx, struct damos **schemes,
 	for (i = 0; i < nr_schemes; i++)
 		damon_add_scheme(ctx, schemes[i]);
 }
+EXPORT_SYMBOL_GPL(damon_set_schemes);
 
 static struct damos_quota_goal *damos_nth_quota_goal(
 		int n, struct damos_quota *q)
@@ -1371,6 +1378,7 @@ int damon_start(struct damon_ctx **ctxs, int nr_ctxs, bool exclusive)
 
 	return err;
 }
+EXPORT_SYMBOL_GPL(damon_start);
 
 /*
  * __damon_stop() - Stops monitoring of a given context.
@@ -1414,6 +1422,7 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs)
 	}
 	return err;
 }
+EXPORT_SYMBOL_GPL(damon_stop);
 
 /**
  * damon_is_running() - Returns if a given DAMON context is running.
@@ -2924,6 +2933,7 @@ bool damon_initialized(void)
 {
 	return damon_region_cache != NULL;
 }
+EXPORT_SYMBOL_GPL(damon_initialized);
 
 static int __init damon_init(void)
 {
-- 
2.43.0

[PATCH 2/2] mm/damon/modules: introduce prdm module for DAMON

[Enze Li]

This commit introduces the 'prdm' module, an acronym for Proactive
Reclamation DAMON-based Module.  The development of this module was
inspired by the existing DAMON sample code (prcl.c), extending its core
idea into a production-ready, user-friendly module.

The key enhancement over the original sample is the capability to
concurrently monitor and perform proactive reclamation for multiple
user-specified processes.  This addresses a significant limitation for
practical deployment, where system-wide memory pressure often originates
from several processes rather than a single one.

While achieving similar proactive reclamation is possible through the
existing damo tool with complex manual configuration, the 'prdm'
module significantly reduces the barrier to entry.  Its primary
advantage is simplicity: users only need to provide the PIDs of the
target processes and enable the module.  This "set PIDs and turn on"
approach encapsulates the intricate DAMON and DAMOS configurations,
making advanced memory optimization accessible to non-expert users
without requiring deep knowledge of the underlying framework.

The module leverages the DAMON framework to track memory access patterns
and utilizes the DAMOS subsystem to trigger reclamation actions on
identified cold memory regions across all monitored processes.

By building upon the proven concept from the DAMON samples, adding
crucial multi-target support, and prioritizing ease of use, 'prdm'
provides a robust and accessible tool for optimizing memory usage in
real-world scenarios.

Signed-off-by: Enze Li <lienze@kylinos.cn>
---
 mm/damon/Kconfig          |   2 +
 mm/damon/Makefile         |   1 +
 mm/damon/modules/Kconfig  |  19 +++
 mm/damon/modules/Makefile |   3 +
 mm/damon/modules/prdm.c   | 254 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 279 insertions(+)
 create mode 100644 mm/damon/modules/Kconfig
 create mode 100644 mm/damon/modules/Makefile
 create mode 100644 mm/damon/modules/prdm.c

diff --git a/mm/damon/Kconfig b/mm/damon/Kconfig
index 8c868f7035fc..12e437d3158c 100644
--- a/mm/damon/Kconfig
+++ b/mm/damon/Kconfig
@@ -110,4 +110,6 @@ config DAMON_STAT_ENABLED_DEFAULT
 	  Whether to enable DAMON_STAT by default.  Users can disable it in
 	  boot or runtime using its 'enabled' parameter.
 
+source "mm/damon/modules/Kconfig"
+
 endmenu
diff --git a/mm/damon/Makefile b/mm/damon/Makefile
index d8d6bf5f8bff..6bfabf546c26 100644
--- a/mm/damon/Makefile
+++ b/mm/damon/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_DAMON_SYSFS)	+= sysfs-common.o sysfs-schemes.o sysfs.o
 obj-$(CONFIG_DAMON_RECLAIM)	+= modules-common.o reclaim.o
 obj-$(CONFIG_DAMON_LRU_SORT)	+= modules-common.o lru_sort.o
 obj-$(CONFIG_DAMON_STAT)	+= modules-common.o stat.o
+obj-$(CONFIG_DAMON_PRDM)	+= modules/
diff --git a/mm/damon/modules/Kconfig b/mm/damon/modules/Kconfig
new file mode 100644
index 000000000000..bce29c0f7224
--- /dev/null
+++ b/mm/damon/modules/Kconfig
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0
+
+menu "DAMON ready-to-use modules"
+
+config DAMON_PRDM
+	tristate "Build proactive reclamation DAMON-based module"
+	depends on DAMON && DAMON_VADDR && m
+	default n
+	help
+	  This builds DAMON module for access-aware proactive reclamation of
+	  multiple processes.
+
+	  The module receives pids, monitor access to the virtual address space
+	  of these processes, find memory regions that not accessed, and
+	  proactively reclaim the regions.
+
+	  If unsure, say N.
+
+endmenu
diff --git a/mm/damon/modules/Makefile b/mm/damon/modules/Makefile
new file mode 100644
index 000000000000..f6ae727410ba
--- /dev/null
+++ b/mm/damon/modules/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_DAMON_PRDM) += prdm.o
diff --git a/mm/damon/modules/prdm.c b/mm/damon/modules/prdm.c
new file mode 100644
index 000000000000..c107902f07c7
--- /dev/null
+++ b/mm/damon/modules/prdm.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * The Proactive Reclamation DAMON-based Module (prdm) is a loadable kernel
+ * module that provides out-of-the-box proactive memory reclamation.  It
+ * monitors the access patterns of specified processes, finds regions that seem
+ * infrequently accessed, and proactively pages out those regions.
+ *
+ * Based on samples/damon/prcl.c written by SeongJae Park <sj@kernel.org>.
+ * This module extends the original by adding support for monitoring multiple
+ * target processes concurrently.
+ *
+ * Author: Enze Li <lienze@kylinos.cn>
+ * Copyright (C) 2025 KylinSoft Corporation.
+ */
+
+#define pr_fmt(fmt) "damon-prdm: " fmt
+
+#include <linux/damon.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#ifdef MODULE_PARAM_PREFIX
+#undef MODULE_PARAM_PREFIX
+#endif
+#define MODULE_PARAM_PREFIX "damon_prdm."
+
+static struct damon_ctx *ctx;
+static LIST_HEAD(target_list);
+static int target_count;
+
+struct prdm_target {
+	struct pid *ppid;
+	int pid;
+	struct list_head list;
+};
+
+static int damon_prdm_target_pid_store(const char *val,
+				       const struct kernel_param *kp);
+static int damon_prdm_target_pid_show(char *buffer,
+				      const struct kernel_param *kp);
+
+static const struct kernel_param_ops target_pid_param_ops = {
+	.set = damon_prdm_target_pid_store,
+	.get = damon_prdm_target_pid_show,
+};
+
+static int target_pid __read_mostly;
+module_param_cb(target_pid, &target_pid_param_ops, &target_pid, 0600);
+MODULE_PARM_DESC(target_pid, "Specifies the pids of the target processes to be monitored");
+
+static int damon_prdm_enable_store(const char *val,
+				   const struct kernel_param *kp);
+
+static const struct kernel_param_ops enabled_param_ops = {
+	.set = damon_prdm_enable_store,
+	.get = param_get_bool,
+};
+
+static bool enabled __read_mostly;
+module_param_cb(enabled, &enabled_param_ops, &enabled, 0600);
+MODULE_PARM_DESC(enabled, "Enable or disable DAMON_PRDM");
+
+static int damon_prdm_start(void)
+{
+	struct damon_target *target;
+	struct damos *scheme;
+	struct prdm_target *t;
+	struct list_head *pos;
+	struct task_struct *task;
+	int err, exist_target_num;
+
+	pr_info("start\n");
+
+	if (target_count <= 0)
+		return -EINVAL;
+
+	ctx = damon_new_ctx();
+	if (!ctx)
+		return -ENOMEM;
+	if (damon_select_ops(ctx, DAMON_OPS_VADDR)) {
+		damon_destroy_ctx(ctx);
+		return -EINVAL;
+	}
+
+	exist_target_num = 0;
+	list_for_each(pos, &target_list) {
+		t = list_entry(pos, struct prdm_target, list);
+		task = get_pid_task(t->ppid, PIDTYPE_PID);
+		if (task) {
+			target = damon_new_target();
+			if (!target) {
+				damon_destroy_ctx(ctx);
+				return -ENOMEM;
+			}
+			target->pid = t->ppid;
+			damon_add_target(ctx, target);
+			exist_target_num++;
+			put_task_struct(task);
+		}
+	}
+
+	if (exist_target_num <= 0)
+		return -EINVAL;
+
+	scheme = damon_new_scheme(
+			&(struct damos_access_pattern) {
+			.min_sz_region = PAGE_SIZE,
+			.max_sz_region = ULONG_MAX,
+			.min_nr_accesses = 0,
+			.max_nr_accesses = 0,
+			.min_age_region = 50,
+			.max_age_region = UINT_MAX},
+			DAMOS_PAGEOUT,
+			0,
+			&(struct damos_quota){},
+			&(struct damos_watermarks){},
+			NUMA_NO_NODE);
+	if (!scheme) {
+		damon_destroy_ctx(ctx);
+		return -ENOMEM;
+	}
+	damon_set_schemes(ctx, &scheme, 1);
+
+	err = damon_start(&ctx, 1, true);
+	if (err)
+		return err;
+
+	return 0;
+}
+
+static void damon_prdm_stop(void)
+{
+	pr_info("stop\n");
+	if (ctx) {
+		damon_stop(&ctx, 1);
+		damon_destroy_ctx(ctx);
+		ctx = NULL;
+	}
+}
+
+static int damon_prdm_target_pid_store(const char *val,
+				       const struct kernel_param *kp)
+{
+	int err;
+	struct prdm_target *pt;
+
+	if (!damon_initialized())
+		return 0;
+
+	err = kstrtoint(val, 0, &target_pid);
+	if (err)
+		return err;
+
+	pt = kmalloc(sizeof(*pt), GFP_KERNEL);
+	if (!pt)
+		return -ENOMEM;
+
+	pt->ppid = find_get_pid(target_pid);
+	pt->pid = target_pid;
+	INIT_LIST_HEAD(&pt->list);
+	list_add_tail(&pt->list, &target_list);
+	target_count++;
+
+	return 0;
+}
+
+static int damon_prdm_target_pid_show(char *buffer,
+				      const struct kernel_param *kp)
+{
+	char buf[1024];
+	struct list_head *pos;
+	struct prdm_target *t;
+	struct task_struct *task;
+	int len = 0;
+
+	if (!damon_initialized())
+		return 0;
+
+	len = snprintf(buf, sizeof(buf), "%s:", "Tasks");
+	list_for_each(pos, &target_list) {
+		t = list_entry(pos, struct prdm_target, list);
+		task = get_pid_task(t->ppid, PIDTYPE_PID);
+		if (task) {
+			len += snprintf(buf + len, sizeof(buf) - len, " %d",
+					t->pid);
+			put_task_struct(task);
+		} else {
+			len += snprintf(buf + len, sizeof(buf) - len,
+					" %d(exited)", t->pid);
+		}
+	}
+
+	return scnprintf(buffer, 1024, "%s\n", buf);
+}
+
+static int damon_prdm_enable_store(const char *val,
+				   const struct kernel_param *kp)
+{
+	bool is_enabled = enabled;
+	int err;
+
+	if (!damon_initialized())
+		return 0;
+
+	err = kstrtobool(val, &enabled);
+	if (err)
+		return err;
+
+	if (enabled == is_enabled)
+		return 0;
+
+	if (enabled) {
+		err = damon_prdm_start();
+		if (err)
+			enabled = false;
+		return err;
+	}
+	damon_prdm_stop();
+	return 0;
+}
+
+static void __exit damon_prdm_exit(void)
+{
+	struct prdm_target *entry, *tmp;
+
+	pr_debug("%s", __func__);
+	damon_prdm_stop();
+
+	list_for_each_entry_safe(entry, tmp, &target_list, list) {
+		list_del(&entry->list);
+		kfree(entry);
+	}
+	INIT_LIST_HEAD(&target_list);
+	target_count = 0;
+}
+
+static int __init damon_prdm_init(void)
+{
+	if (!damon_initialized()) {
+		if (enabled)
+			enabled = false;
+		return -ENOMEM;
+	}
+
+	pr_debug("%s", __func__);
+	return 0;
+}
+
+module_init(damon_prdm_init);
+module_exit(damon_prdm_exit);
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("A DAMON module for proactive reclamation of multiple processes");
+MODULE_AUTHOR("SeongJae Park <sj@kernel.org>, Enze Li <lienze@kylinos.cn>");
-- 
2.43.0

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[SeongJae Park]

Hello Enze,

On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:

> This patchset makes DAMON's advanced memory management accessible to a
> broader range of users through two complementary enhancements.  First,
> it exports the necessary DAMON core symbols to enable building loadable
> kernel modules.  Building on this foundation, it then introduces the
> 'prdm' module, which extends the concept from the DAMON sample code
> (prcl.c) into a production-ready, user-friendly tool.
> 
> The key strength of this module is its out-of-the-box simplicity: by
> simply specifying the PIDs of target processes and enabling the module,
> users can concurrently monitor memory access patterns across multiple
> processes and trigger proactive reclamation automatically.  This
> significantly lowers the barrier to using DAMON, allowing system
> administrators and regular users without deep kernel expertise to easily
> apply sophisticated memory optimization.

I agree your points about the problems and the direction for improving the
situation.  However, we have a module for such use case, namely DAMON_RECLAIM.
It was designed for a reason that very same to what you described above.  One
key difference between DAMON_RECLAIM and prdm is, to my understanding,
DAMON_RECLAIM works for the physical address space, while prdm works for
virtual address spaces.  Is the virtual address spaces proactive reclamation is
what you really need?  If so, could you please further describe your expected
or planned usage of it?

If the virtual address spaces proactive reclamation is really what you need, I
think extending DAMON_RECLAIM for the purpose might be doable and even simpler
than introducing a new module.  How about doing so?

And, even more importantly, why it should be a loadable module rather than a
static module?  Do you have a specific use case that requires it to be a
loadable module?


Thanks,
SJ

[...]

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[Enze Li]

On 2025/12/16 07:16, SeongJae Park wrote:
> Hello Enze,
> 
> On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> 
>> This patchset makes DAMON's advanced memory management accessible to a
>> broader range of users through two complementary enhancements.  First,
>> it exports the necessary DAMON core symbols to enable building loadable
>> kernel modules.  Building on this foundation, it then introduces the
>> 'prdm' module, which extends the concept from the DAMON sample code
>> (prcl.c) into a production-ready, user-friendly tool.
>>
>> The key strength of this module is its out-of-the-box simplicity: by
>> simply specifying the PIDs of target processes and enabling the module,
>> users can concurrently monitor memory access patterns across multiple
>> processes and trigger proactive reclamation automatically.  This
>> significantly lowers the barrier to using DAMON, allowing system
>> administrators and regular users without deep kernel expertise to easily
>> apply sophisticated memory optimization.
> 
> I agree your points about the problems and the direction for improving the
> situation.

Thank you, SJ!  Glad we are on the same page. :)

> However, we have a module for such use case, namely DAMON_RECLAIM.
> It was designed for a reason that very same to what you described above.  One
> key difference between DAMON_RECLAIM and prdm is, to my understanding,
> DAMON_RECLAIM works for the physical address space, while prdm works for
> virtual address spaces.

Yes, I have studied the implementation and architecture of this module
quite thoroughly.  However, there are certain limitations when
considering it for production use.  To my knowledge, few would perform
indiscriminate page reclamation across the entire system.  In most
practical scenarios, people prefer to protect critical processes from
being swapped out, while applying page migration and reclamation only to
less critical or performance-insensitive processes.

As we all know, frequent page migration inevitably introduces some
latency to process response times.  Therefore, the ability to target
large, inactive memory consumers for reclamation addresses a strong,
genuine demand from real production environments.

> Is the virtual address spaces proactive reclamation is
> what you really need?  If so, could you please further describe your expected
> or planned usage of it?

Consider the following scenario: a host machine runs three virtual
machines -- Machine A, Machine B, and Machine C.  It is known that
Machine A handles massive traffic, while Machines B and C have
relatively light workloads.  When memory pressure arises, besides
releasing caches, the system can utilize prdm to perform precise page
migration targeting Machines B and C, ensuring memory usage remains
within a safe margin.

The data below, collected from a test environment, demonstrates the
effectiveness of prdm.  After enabling prdm to monitor the two
lower-activity VMs (2316, 2284), I observed that the DAMON-based prdm
successfully migrated 5.5 GB of pages to the swap partition.

 PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2253 qemu  20   0 11.251g 3.822g  32.7m S 4.989 12.28   0:48.75
qemu-system-x86
2316 qemu  20   0 12.191g 1.524g  34.3m S 5.322 4.893   0:49.05
qemu-system-x86
2284 qemu  20   0 12.092g 1.184g  32.5m S 5.987 3.803   0:48.10
qemu-system-x86

root@localhost /s/m/p/parameters# free -h
       total        used        free      shared  buff/cache   available
Mem:    31Gi        12Gi        15Gi       5.5Mi       3.2Gi        18Gi
Swap:   31Gi       5.5Gi        25Gi

> 
> If the virtual address spaces proactive reclamation is really what you need, I
> think extending DAMON_RECLAIM for the purpose might be doable and even simpler
> than introducing a new module.  How about doing so?

Before developing prdm, I had considered implementing the same
functionality based on DAMON_RECLAIM.  However, I gradually realized
this would make DAMON_RECLAIM overly complex and less
user-friendly—especially given its existing module-specific exported
interfaces, which could confuse users.  This approach would create
significant barriers to promoting wider DAMON adoption.  Consequently,
building upon the prcl sample became the preferred choice.

> 
> And, even more importantly, why it should be a loadable module rather than a
> static module?  Do you have a specific use case that requires it to be a
> loadable module?

Yes, loadability is crucial for operational flexibility in practical
production environments.  Beyond some obvious advantages, I would like
to highlight a key scenario: system administrators can load the prdm
module upon detecting memory pressure and unload it immediately after
reclamation is complete, thereby eliminating any overhead during normal
operation.  Furthermore, it supports zero-downtime updates, meaning that
improvements targeting prdm can be deployed via a simple module reload,
avoiding costly system reboots.

Finally, I would like to add that designing prdm with an extremely
simple workflow -- load the module, set the target PIDs, and enable the
switch -- will contribute to the promotion of DAMON, allowing a broader
user base to benefit from the DAMON system.

Best Regards,
Enze

<...>

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[SeongJae Park]

On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:

> On 2025/12/16 07:16, SeongJae Park wrote:
> > Hello Enze,
> > 
> > On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > 
> >> This patchset makes DAMON's advanced memory management accessible to a
> >> broader range of users through two complementary enhancements.  First,
> >> it exports the necessary DAMON core symbols to enable building loadable
> >> kernel modules.  Building on this foundation, it then introduces the
> >> 'prdm' module, which extends the concept from the DAMON sample code
> >> (prcl.c) into a production-ready, user-friendly tool.
> >>
> >> The key strength of this module is its out-of-the-box simplicity: by
> >> simply specifying the PIDs of target processes and enabling the module,
> >> users can concurrently monitor memory access patterns across multiple
> >> processes and trigger proactive reclamation automatically.  This
> >> significantly lowers the barrier to using DAMON, allowing system
> >> administrators and regular users without deep kernel expertise to easily
> >> apply sophisticated memory optimization.
> > 
> > I agree your points about the problems and the direction for improving the
> > situation.
> 
> Thank you, SJ!  Glad we are on the same page. :)
> 
> > However, we have a module for such use case, namely DAMON_RECLAIM.
> > It was designed for a reason that very same to what you described above.  One
> > key difference between DAMON_RECLAIM and prdm is, to my understanding,
> > DAMON_RECLAIM works for the physical address space, while prdm works for
> > virtual address spaces.
> 
> Yes, I have studied the implementation and architecture of this module
> quite thoroughly.  However, there are certain limitations when
> considering it for production use.

To my understanding, DAMON_RECLAIM is being used in multiple real world
products.  I understand you are saying there could be limitations for some
different production uses, and I agree.

> To my knowledge, few would perform
> indiscriminate page reclamation across the entire system.  In most
> practical scenarios, people prefer to protect critical processes from
> being swapped out, while applying page migration and reclamation only to
> less critical or performance-insensitive processes.

Thank you for kindly explaining above.  I agree such protection of critical
processes could be useful and required.  Nonetheless, to me, it sounds like you
could also do such protection using DAMOS_FILTER_TYPE_MEMCG.  Actually the
feature was developed for such use cases, and I recently met some people who
willing to use DAMON on their products in a way very similar to what you
described.  I suggested them to try DAMOS_FILTER_TYPE_MEMCG.  Have you
considered using DAMOS_FILTER_TYPE_MEMCG?

> 
> As we all know, frequent page migration inevitably introduces some
> latency to process response times.  Therefore, the ability to target
> large, inactive memory consumers for reclamation addresses a strong,
> genuine demand from real production environments.
> 
> > Is the virtual address spaces proactive reclamation is
> > what you really need?  If so, could you please further describe your expected
> > or planned usage of it?
> 
> Consider the following scenario: a host machine runs three virtual
> machines -- Machine A, Machine B, and Machine C.  It is known that
> Machine A handles massive traffic, while Machines B and C have
> relatively light workloads.  When memory pressure arises, besides
> releasing caches, the system can utilize prdm to perform precise page
> migration targeting Machines B and C, ensuring memory usage remains
> within a safe margin.
> 
> The data below, collected from a test environment, demonstrates the
> effectiveness of prdm.  After enabling prdm to monitor the two
> lower-activity VMs (2316, 2284), I observed that the DAMON-based prdm
> successfully migrated 5.5 GB of pages to the swap partition.
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
> 2253 qemu  20   0 11.251g 3.822g  32.7m S 4.989 12.28   0:48.75
> qemu-system-x86
> 2316 qemu  20   0 12.191g 1.524g  34.3m S 5.322 4.893   0:49.05
> qemu-system-x86
> 2284 qemu  20   0 12.092g 1.184g  32.5m S 5.987 3.803   0:48.10
> qemu-system-x86
> 
> root@localhost /s/m/p/parameters# free -h
>        total        used        free      shared  buff/cache   available
> Mem:    31Gi        12Gi        15Gi       5.5Mi       3.2Gi        18Gi
> Swap:   31Gi       5.5Gi        25Gi

Thank you for sharing this nice explanation use case.  I think this all make
sense.

> 
> > 
> > If the virtual address spaces proactive reclamation is really what you need, I
> > think extending DAMON_RECLAIM for the purpose might be doable and even simpler
> > than introducing a new module.  How about doing so?
> 
> Before developing prdm, I had considered implementing the same
> functionality based on DAMON_RECLAIM.  However, I gradually realized
> this would make DAMON_RECLAIM overly complex and less
> user-friendly—especially given its existing module-specific exported
> interfaces, which could confuse users.  This approach would create
> significant barriers to promoting wider DAMON adoption.  Consequently,
> building upon the prcl sample became the preferred choice.

I agree DAMON_RECLAIM already have no small number of parameters, and adding
more may make it look even more complex.  But, users may use only parameters
that really need to be set for their real use case.

For example, if we implement virtual address spaces mode in DAMON_RECLAIM, I
think we can simply add target_pid parameter that works very same to that of
prdm.  If it is unset, DAMON_RECLAIM works in the physical address mode.  If it
is set, it works in the virtual address mode.  Adding just one more parameter
that doesn't break old usage doesn't seem that complex change to me, at least
in terms of the user experience.

As I mentioned above, yet another example would be using
DAMOS_FILTER_TYPE_MEMCG.  For this, we may be able to add a parameter for
describing the memcg of critical processes.  Again, adding just one more
parameter that doesn't affect old usages doesn't seem too complex changes to
me, at least in terms of the user experience.

Meanwhile, I agree adding a new simpler module could make it easy for new
users.  But, I concern if having two modules for DAMON-based reclamation will
make users get difficulty at finding the correct one for their usage, since
they may now need to compare two modules.

For the above reasons, I still feel extending DAMON_RECLAIM is a better
approach in terms of user experience.

I'm not saying DAMON_RECLAIM's user interface is perfect.  Especially its
documentation may have many rooms to improve.

And I'm not very sure if the virtual address spaces reclamation is somewhat
need to be supported from modules rather than using DAMON sysfs interface or
DAMON user-space tool.  I implemented DAMON modules including DAMON_RECLAIM,
DAMON_LRU_SORT and DAMON_STAT for users who willing to enable those always, and
therefore want to avoid runtime controls.  That is, users can use those modules
by modifying the kernel command line options.  My expectation for DAMON modules
may not well documented.  If so, it's my bad.  I will try to recheck the
documentation and make that more clearly documented.

For virtual address spaces reclamation, however, runtime control is essential
since you don't know the pid of the processes before the runtime.  In the case,
I think using DAMON sysfs interface or DAMON user-space tool could be a better
approach.  Have you considered using those?

> 
> > 
> > And, even more importantly, why it should be a loadable module rather than a
> > static module?  Do you have a specific use case that requires it to be a
> > loadable module?
> 
> Yes, loadability is crucial for operational flexibility in practical
> production environments.  Beyond some obvious advantages, I would like
> to highlight a key scenario: system administrators can load the prdm
> module upon detecting memory pressure and unload it immediately after
> reclamation is complete, thereby eliminating any overhead during normal
> operation.

I agree always having prdm in kernel is an overhead.  But, I think the
overhead is not meaningfully big.  Also, as I mentioned above, my intended use
cases of DAMON modules is for cases that willing to simply always use the
modules.  If runtime controls are essential, I think using DAMON sysfs
interface or DAMON user-space tool is a better choice.

Someone might argue DAMON sysfs interface is unnecessarily big compared to
prdm.  But, I have to ask again in the case.  Does the overhead really
meaningfully big for a real world use case?

> Furthermore, it supports zero-downtime updates, meaning that
> improvements targeting prdm can be deployed via a simple module reload,
> avoiding costly system reboots.

So I'm not really convinced at needs of prdm module at the moment.  But I agree
your above point is a good example advantage of loadable modules.  Also there
were private requests to support loadable DAMON modules.  No one among those
were for real production use case, and I understand you are also doing this
work for imaginable use cases, not your real products.  Please correct me if
I'm wrong.  But as the request is repeated, if you willing to convert existing
DAMON modules to support loadable modules build and expose required DAMON
functions for that, at least I wouldn't oppose.

> 
> Finally, I would like to add that designing prdm with an extremely
> simple workflow -- load the module, set the target PIDs, and enable the
> switch -- will contribute to the promotion of DAMON, allowing a broader
> user base to benefit from the DAMON system.

That workflow is definitely much easier than directly using DAMON sysfs
interface.  But, for the reason we have DAMON user-space tool.  Using it, the
workflow can also be as simple as prdm, like below.

   # damo start $TARGET_PID --damos_action pageout --damos_access_rate 0% 0% --damos_age 2m max


Thanks,
SJ

[...]

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[JaeJoon Jung]

On Fri, 19 Dec 2025 at 21:52, SeongJae Park <sj@kernel.org> wrote:
>
> On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
>
> > On 2025/12/16 07:16, SeongJae Park wrote:
> > > Hello Enze,
> > >
> > > On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > >
> > >> This patchset makes DAMON's advanced memory management accessible to a
> > >> broader range of users through two complementary enhancements.  First,
> > >> it exports the necessary DAMON core symbols to enable building loadable
> > >> kernel modules.  Building on this foundation, it then introduces the
> > >> 'prdm' module, which extends the concept from the DAMON sample code
> > >> (prcl.c) into a production-ready, user-friendly tool.
> > >>
> > >> The key strength of this module is its out-of-the-box simplicity: by
> > >> simply specifying the PIDs of target processes and enabling the module,
> > >> users can concurrently monitor memory access patterns across multiple
> > >> processes and trigger proactive reclamation automatically.  This
> > >> significantly lowers the barrier to using DAMON, allowing system
> > >> administrators and regular users without deep kernel expertise to easily
> > >> apply sophisticated memory optimization.
> > >
> > > I agree your points about the problems and the direction for improving the
> > > situation.
> >
> > Thank you, SJ!  Glad we are on the same page. :)
> >
> > > However, we have a module for such use case, namely DAMON_RECLAIM.
> > > It was designed for a reason that very same to what you described above.  One
> > > key difference between DAMON_RECLAIM and prdm is, to my understanding,
> > > DAMON_RECLAIM works for the physical address space, while prdm works for
> > > virtual address spaces.
> >
> > Yes, I have studied the implementation and architecture of this module
> > quite thoroughly.  However, there are certain limitations when
> > considering it for production use.
>
> To my understanding, DAMON_RECLAIM is being used in multiple real world
> products.  I understand you are saying there could be limitations for some
> different production uses, and I agree.
>
> > To my knowledge, few would perform
> > indiscriminate page reclamation across the entire system.  In most
> > practical scenarios, people prefer to protect critical processes from
> > being swapped out, while applying page migration and reclamation only to
> > less critical or performance-insensitive processes.
>
> Thank you for kindly explaining above.  I agree such protection of critical
> processes could be useful and required.  Nonetheless, to me, it sounds like you
> could also do such protection using DAMOS_FILTER_TYPE_MEMCG.  Actually the
> feature was developed for such use cases, and I recently met some people who
> willing to use DAMON on their products in a way very similar to what you
> described.  I suggested them to try DAMOS_FILTER_TYPE_MEMCG.  Have you
> considered using DAMOS_FILTER_TYPE_MEMCG?
>
> >
> > As we all know, frequent page migration inevitably introduces some
> > latency to process response times.  Therefore, the ability to target
> > large, inactive memory consumers for reclamation addresses a strong,
> > genuine demand from real production environments.
> >
> > > Is the virtual address spaces proactive reclamation is
> > > what you really need?  If so, could you please further describe your expected
> > > or planned usage of it?
> >
> > Consider the following scenario: a host machine runs three virtual
> > machines -- Machine A, Machine B, and Machine C.  It is known that
> > Machine A handles massive traffic, while Machines B and C have
> > relatively light workloads.  When memory pressure arises, besides
> > releasing caches, the system can utilize prdm to perform precise page
> > migration targeting Machines B and C, ensuring memory usage remains
> > within a safe margin.
> >
> > The data below, collected from a test environment, demonstrates the
> > effectiveness of prdm.  After enabling prdm to monitor the two
> > lower-activity VMs (2316, 2284), I observed that the DAMON-based prdm
> > successfully migrated 5.5 GB of pages to the swap partition.
> >
> >  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
> > 2253 qemu  20   0 11.251g 3.822g  32.7m S 4.989 12.28   0:48.75
> > qemu-system-x86
> > 2316 qemu  20   0 12.191g 1.524g  34.3m S 5.322 4.893   0:49.05
> > qemu-system-x86
> > 2284 qemu  20   0 12.092g 1.184g  32.5m S 5.987 3.803   0:48.10
> > qemu-system-x86
> >
> > root@localhost /s/m/p/parameters# free -h
> >        total        used        free      shared  buff/cache   available
> > Mem:    31Gi        12Gi        15Gi       5.5Mi       3.2Gi        18Gi
> > Swap:   31Gi       5.5Gi        25Gi
>
> Thank you for sharing this nice explanation use case.  I think this all make
> sense.
>
> >
> > >
> > > If the virtual address spaces proactive reclamation is really what you need, I
> > > think extending DAMON_RECLAIM for the purpose might be doable and even simpler
> > > than introducing a new module.  How about doing so?
> >
> > Before developing prdm, I had considered implementing the same
> > functionality based on DAMON_RECLAIM.  However, I gradually realized
> > this would make DAMON_RECLAIM overly complex and less
> > user-friendly—especially given its existing module-specific exported
> > interfaces, which could confuse users.  This approach would create
> > significant barriers to promoting wider DAMON adoption.  Consequently,
> > building upon the prcl sample became the preferred choice.
>
> I agree DAMON_RECLAIM already have no small number of parameters, and adding
> more may make it look even more complex.  But, users may use only parameters
> that really need to be set for their real use case.
>
> For example, if we implement virtual address spaces mode in DAMON_RECLAIM, I
> think we can simply add target_pid parameter that works very same to that of
> prdm.  If it is unset, DAMON_RECLAIM works in the physical address mode.  If it
> is set, it works in the virtual address mode.  Adding just one more parameter
> that doesn't break old usage doesn't seem that complex change to me, at least
> in terms of the user experience.
>
> As I mentioned above, yet another example would be using
> DAMOS_FILTER_TYPE_MEMCG.  For this, we may be able to add a parameter for
> describing the memcg of critical processes.  Again, adding just one more
> parameter that doesn't affect old usages doesn't seem too complex changes to
> me, at least in terms of the user experience.
>
> Meanwhile, I agree adding a new simpler module could make it easy for new
> users.  But, I concern if having two modules for DAMON-based reclamation will
> make users get difficulty at finding the correct one for their usage, since
> they may now need to compare two modules.
>
> For the above reasons, I still feel extending DAMON_RECLAIM is a better
> approach in terms of user experience.
>
> I'm not saying DAMON_RECLAIM's user interface is perfect.  Especially its
> documentation may have many rooms to improve.
>
> And I'm not very sure if the virtual address spaces reclamation is somewhat
> need to be supported from modules rather than using DAMON sysfs interface or
> DAMON user-space tool.  I implemented DAMON modules including DAMON_RECLAIM,
> DAMON_LRU_SORT and DAMON_STAT for users who willing to enable those always, and
> therefore want to avoid runtime controls.  That is, users can use those modules
> by modifying the kernel command line options.  My expectation for DAMON modules
> may not well documented.  If so, it's my bad.  I will try to recheck the
> documentation and make that more clearly documented.
>
> For virtual address spaces reclamation, however, runtime control is essential
> since you don't know the pid of the processes before the runtime.  In the case,
> I think using DAMON sysfs interface or DAMON user-space tool could be a better
> approach.  Have you considered using those?
>
> >
> > >
> > > And, even more importantly, why it should be a loadable module rather than a
> > > static module?  Do you have a specific use case that requires it to be a
> > > loadable module?
> >
> > Yes, loadability is crucial for operational flexibility in practical
> > production environments.  Beyond some obvious advantages, I would like
> > to highlight a key scenario: system administrators can load the prdm
> > module upon detecting memory pressure and unload it immediately after
> > reclamation is complete, thereby eliminating any overhead during normal
> > operation.
>
> I agree always having prdm in kernel is an overhead.  But, I think the
> overhead is not meaningfully big.  Also, as I mentioned above, my intended use
> cases of DAMON modules is for cases that willing to simply always use the
> modules.  If runtime controls are essential, I think using DAMON sysfs
> interface or DAMON user-space tool is a better choice.

I also think the current DAMON design structure is suitable for DAMON sysfs
and user-space tools.  DAMON sysfs can run multiple nr_ctxs, so I think it
would be a good idea to consolidate it into this.  As Enze mentioned, DAMON
was originally designed as a kernel loadable module, but I was curious as to
why it wasn't run that way.  When executing the damon_start(**ctxs,
nr_ctxs, exclusive)
function, nr_ctxs=1, exclusive=true is passed so that modules are currently
executed only one at a time.  Therefore, there is no point in running
DAMON
as a kernel module, since you are not running multiple modules simultaneously.
I'm doing some more research into why we run modules with exclusive=true.
One more thing I would like to add is that I think it would be less
confusing
to move lru_sort and reclaim to the samples/damon/ path.  And it would
be
a good idea to organize the core sources toward
mm/damon/modules-common.c source.

>
> Someone might argue DAMON sysfs interface is unnecessarily big compared to
> prdm.  But, I have to ask again in the case.  Does the overhead really
> meaningfully big for a real world use case?
>
> > Furthermore, it supports zero-downtime updates, meaning that
> > improvements targeting prdm can be deployed via a simple module reload,
> > avoiding costly system reboots.
>
> So I'm not really convinced at needs of prdm module at the moment.  But I agree
> your above point is a good example advantage of loadable modules.  Also there
> were private requests to support loadable DAMON modules.  No one among those
> were for real production use case, and I understand you are also doing this
> work for imaginable use cases, not your real products.  Please correct me if
> I'm wrong.  But as the request is repeated, if you willing to convert existing
> DAMON modules to support loadable modules build and expose required DAMON
> functions for that, at least I wouldn't oppose.
>
> >
> > Finally, I would like to add that designing prdm with an extremely
> > simple workflow -- load the module, set the target PIDs, and enable the
> > switch -- will contribute to the promotion of DAMON, allowing a broader
> > user base to benefit from the DAMON system.
>
> That workflow is definitely much easier than directly using DAMON sysfs
> interface.  But, for the reason we have DAMON user-space tool.  Using it, the
> workflow can also be as simple as prdm, like below.
>
>    # damo start $TARGET_PID --damos_action pageout --damos_access_rate 0% 0% --damos_age 2m max

Where can I find the damo source or documentation?

Thanks,
JaeJoon

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

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[SeongJae Park]

On Sun, 21 Dec 2025 11:42:43 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:

> On Fri, 19 Dec 2025 at 21:52, SeongJae Park <sj@kernel.org> wrote:
> >
> > On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
> >
> > > On 2025/12/16 07:16, SeongJae Park wrote:
> > > > Hello Enze,
> > > >
> > > > On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
[...]
> > If runtime controls are essential, I think using DAMON sysfs
> > interface or DAMON user-space tool is a better choice.
> 
> I also think the current DAMON design structure is suitable for DAMON sysfs
> and user-space tools.  DAMON sysfs can run multiple nr_ctxs, so I think it
> would be a good idea to consolidate it into this.  As Enze mentioned, DAMON
> was originally designed as a kernel loadable module,

I don't recall where Enze mentioned so.  Could you please give me a pointer?

And I'm not sure based on what you are saying it was originally designed as a
loadable module.  Maybe you are saying something before DAMON's mainline
landing, but that's quite long ago and my memory management is not good.  Could
you please add more contexts?

> but I was curious as to
> why it wasn't run that way.

Maybe I could give you an answer if you could give me the context that I asked
above.

> When executing the damon_start(**ctxs,
> nr_ctxs, exclusive)
> function, nr_ctxs=1, exclusive=true is passed so that modules are currently
> executed only one at a time.  Therefore, there is no point in running
> DAMON
> as a kernel module, since you are not running multiple modules simultaneously.

I'm not following your point well.  Could you please elaborate your point?

> I'm doing some more research into why we run modules with exclusive=true.

Hoplefully commit 8b9b0d335a34 ("mm/damon/core: allow non-exclusive DAMON
start/stop") will give you more contexts.

To summarize again, the intention is to avoid kdamonds interrupting each
other's access checks.  For example, suppose the DAMON context for
DAMON_RECLAIM and another one (could be created by DAMON sysfs interface users
or other DAMON modules, say, DAMON_STAT) are running concurrently.  And if
those pick a same page as access check sampling target, their finding of the
access on the page depend on a race condition.  To avoid such a case, DAMON
modules call damon_start() with exclusive argument set.

Maybe this is unclearly documented.  I will recheck the documentation and
improve it to make this more clear.  If you find the rooms to improve and have
ideas for the improvements, please feel free to send patches.

> One more thing I would like to add is that I think it would be less
> confusing
> to move lru_sort and reclaim to the samples/damon/ path.

No, I don't think so.  Those are for real world products, not for samples.

> And it would
> be
> a good idea to organize the core sources toward
> mm/damon/modules-common.c source.

I don't find exactly what kind of reorganization you mean.  But I agree there
could be rooms to improve in terms of the files and code organization.  Any
suggestion is welcome.

[...]
> > > Finally, I would like to add that designing prdm with an extremely
> > > simple workflow -- load the module, set the target PIDs, and enable the
> > > switch -- will contribute to the promotion of DAMON, allowing a broader
> > > user base to benefit from the DAMON system.
> >
> > That workflow is definitely much easier than directly using DAMON sysfs
> > interface.  But, for the reason we have DAMON user-space tool.  Using it, the
> > workflow can also be as simple as prdm, like below.
> >
> >    # damo start $TARGET_PID --damos_action pageout --damos_access_rate 0% 0% --damos_age 2m max
> 
> Where can I find the damo source or documentation?

You could use https://github.com/damonitor/damo and its README.md file.


Thanks,
SJ

[...]

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[JaeJoon Jung]

On Sun, 21 Dec 2025 at 17:12, SeongJae Park <sj@kernel.org> wrote:
>
> On Sun, 21 Dec 2025 11:42:43 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
>
> > On Fri, 19 Dec 2025 at 21:52, SeongJae Park <sj@kernel.org> wrote:
> > >
> > > On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > >
> > > > On 2025/12/16 07:16, SeongJae Park wrote:
> > > > > Hello Enze,
> > > > >
> > > > > On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> [...]
> > > If runtime controls are essential, I think using DAMON sysfs
> > > interface or DAMON user-space tool is a better choice.
> >
> > I also think the current DAMON design structure is suitable for DAMON sysfs
> > and user-space tools.  DAMON sysfs can run multiple nr_ctxs, so I think it
> > would be a good idea to consolidate it into this.  As Enze mentioned, DAMON
> > was originally designed as a kernel loadable module,
>
> I don't recall where Enze mentioned so.  Could you please give me a pointer?

Although Enze did not directly state this, His patch is a loadable module,
which implies that it was "designed as a kernel loadable module."

>
> And I'm not sure based on what you are saying it was originally designed as a
> loadable module.  Maybe you are saying something before DAMON's mainline
> landing, but that's quite long ago and my memory management is not good.  Could
> you please add more contexts?
>
> > but I was curious as to
> > why it wasn't run that way.
>
> Maybe I could give you an answer if you could give me the context that I asked
> above.
>
> > When executing the damon_start(**ctxs,
> > nr_ctxs, exclusive)
> > function, nr_ctxs=1, exclusive=true is passed so that modules are currently
> > executed only one at a time.  Therefore, there is no point in running
> > DAMON
> > as a kernel module, since you are not running multiple modules simultaneously.
>
> I'm not following your point well.  Could you please elaborate your point?

So far in my view, I have analyzed DAMON as follows:

DAMON core  <---------> kernel module   <------> damo(user-space)
mm/damon/core.c         mm/damon/lru_sort.c
mm/damon/vaddr.c        mm/damon/reclaim.c
mm/damon/paddr.c        samples/damon/*.c
mm/damon/sysfs.c

Above, lru_sort and reclaim are DAMON core characteristics, but they have
a kernel module structure because they are executed with module_init().
I personally think this is inappropriate.  Additionally, currently, DAMON is
executed only once at a time according to the exclusive=true condition
when damon_start() is called.  In this structure, I believe that the meaning
of "kernel loadable module"  is non-existent.

>
> > I'm doing some more research into why we run modules with exclusive=true.
>
> Hoplefully commit 8b9b0d335a34 ("mm/damon/core: allow non-exclusive DAMON
> start/stop") will give you more contexts.
>
> To summarize again, the intention is to avoid kdamonds interrupting each
> other's access checks.  For example, suppose the DAMON context for
> DAMON_RECLAIM and another one (could be created by DAMON sysfs interface users
> or other DAMON modules, say, DAMON_STAT) are running concurrently.  And if
> those pick a same page as access check sampling target, their finding of the
> access on the page depend on a race condition.  To avoid such a case, DAMON
> modules call damon_start() with exclusive argument set.
>
> Maybe this is unclearly documented.  I will recheck the documentation and
> improve it to make this more clear.  If you find the rooms to improve and have
> ideas for the improvements, please feel free to send patches.
>
> > One more thing I would like to add is that I think it would be less
> > confusing
> > to move lru_sort and reclaim to the samples/damon/ path.
>
> No, I don't think so.  Those are for real world products, not for samples.
>
> > And it would
> > be
> > a good idea to organize the core sources toward
> > mm/damon/modules-common.c source.
>
> I don't find exactly what kind of reorganization you mean.  But I agree there
> could be rooms to improve in terms of the files and code organization.  Any
> suggestion is welcome.
>
> [...]
> > > > Finally, I would like to add that designing prdm with an extremely
> > > > simple workflow -- load the module, set the target PIDs, and enable the
> > > > switch -- will contribute to the promotion of DAMON, allowing a broader
> > > > user base to benefit from the DAMON system.
> > >
> > > That workflow is definitely much easier than directly using DAMON sysfs
> > > interface.  But, for the reason we have DAMON user-space tool.  Using it, the
> > > workflow can also be as simple as prdm, like below.
> > >
> > >    # damo start $TARGET_PID --damos_action pageout --damos_access_rate 0% 0% --damos_age 2m max
> >
> > Where can I find the damo source or documentation?
>
> You could use https://github.com/damonitor/damo and its README.md file.

Thank you so much for sharing.  I am trying to analyze the related contents
in more detail to improve your DAMON.  I'll try to organize it a bit better
and send you a patch.

Thanks,
JaeJoon

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

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[SeongJae Park]

On Sun, 21 Dec 2025 20:04:23 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:

> On Sun, 21 Dec 2025 at 17:12, SeongJae Park <sj@kernel.org> wrote:
> >
> > On Sun, 21 Dec 2025 11:42:43 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
> >
> > > On Fri, 19 Dec 2025 at 21:52, SeongJae Park <sj@kernel.org> wrote:
> > > >
> > > > On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > > >
> > > > > On 2025/12/16 07:16, SeongJae Park wrote:
> > > > > > Hello Enze,
> > > > > >
> > > > > > On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > [...]
> > > > If runtime controls are essential, I think using DAMON sysfs
> > > > interface or DAMON user-space tool is a better choice.
> > >
> > > I also think the current DAMON design structure is suitable for DAMON sysfs
> > > and user-space tools.  DAMON sysfs can run multiple nr_ctxs, so I think it
> > > would be a good idea to consolidate it into this.  As Enze mentioned, DAMON
> > > was originally designed as a kernel loadable module,
> >
> > I don't recall where Enze mentioned so.  Could you please give me a pointer?
> 
> Although Enze did not directly state this, His patch is a loadable module,
> which implies that it was "designed as a kernel loadable module."

Thanks for clarifying.  I understand you are saying Enze's prdm module is
designed as a loadable module, while you are not saying about other parts of
DAMON.

> 
> >
> > And I'm not sure based on what you are saying it was originally designed as a
> > loadable module.  Maybe you are saying something before DAMON's mainline
> > landing, but that's quite long ago and my memory management is not good.  Could
> > you please add more contexts?
> >
> > > but I was curious as to
> > > why it wasn't run that way.
> >
> > Maybe I could give you an answer if you could give me the context that I asked
> > above.
> >
> > > When executing the damon_start(**ctxs,
> > > nr_ctxs, exclusive)
> > > function, nr_ctxs=1, exclusive=true is passed so that modules are currently
> > > executed only one at a time.  Therefore, there is no point in running
> > > DAMON
> > > as a kernel module, since you are not running multiple modules simultaneously.
> >
> > I'm not following your point well.  Could you please elaborate your point?
> 
> So far in my view, I have analyzed DAMON as follows:
> 
> DAMON core  <---------> kernel module   <------> damo(user-space)
> mm/damon/core.c         mm/damon/lru_sort.c
> mm/damon/vaddr.c        mm/damon/reclaim.c
> mm/damon/paddr.c        samples/damon/*.c
> mm/damon/sysfs.c
> 
> Above, lru_sort and reclaim are DAMON core characteristics, but they have
> a kernel module structure because they are executed with module_init().
> I personally think this is inappropriate.

Could you please further clarify why you think it is inappropriate?

> Additionally, currently, DAMON is
> executed only once at a time according to the exclusive=true condition
> when damon_start() is called.  In this structure, I believe that the meaning
> of "kernel loadable module"  is non-existent.

I have to say I still don't get your points.  More elaboration would be nice.

> 
> >
> > > I'm doing some more research into why we run modules with exclusive=true.
> >
> > Hoplefully commit 8b9b0d335a34 ("mm/damon/core: allow non-exclusive DAMON
> > start/stop") will give you more contexts.
> >
> > To summarize again, the intention is to avoid kdamonds interrupting each
> > other's access checks.  For example, suppose the DAMON context for
> > DAMON_RECLAIM and another one (could be created by DAMON sysfs interface users
> > or other DAMON modules, say, DAMON_STAT) are running concurrently.  And if
> > those pick a same page as access check sampling target, their finding of the
> > access on the page depend on a race condition.  To avoid such a case, DAMON
> > modules call damon_start() with exclusive argument set.
> >
> > Maybe this is unclearly documented.  I will recheck the documentation and
> > improve it to make this more clear.  If you find the rooms to improve and have
> > ideas for the improvements, please feel free to send patches.
> >
> > > One more thing I would like to add is that I think it would be less
> > > confusing
> > > to move lru_sort and reclaim to the samples/damon/ path.
> >
> > No, I don't think so.  Those are for real world products, not for samples.
> >
> > > And it would
> > > be
> > > a good idea to organize the core sources toward
> > > mm/damon/modules-common.c source.
> >
> > I don't find exactly what kind of reorganization you mean.  But I agree there
> > could be rooms to improve in terms of the files and code organization.  Any
> > suggestion is welcome.
> >
> > [...]
> > > > > Finally, I would like to add that designing prdm with an extremely
> > > > > simple workflow -- load the module, set the target PIDs, and enable the
> > > > > switch -- will contribute to the promotion of DAMON, allowing a broader
> > > > > user base to benefit from the DAMON system.
> > > >
> > > > That workflow is definitely much easier than directly using DAMON sysfs
> > > > interface.  But, for the reason we have DAMON user-space tool.  Using it, the
> > > > workflow can also be as simple as prdm, like below.
> > > >
> > > >    # damo start $TARGET_PID --damos_action pageout --damos_access_rate 0% 0% --damos_age 2m max
> > >
> > > Where can I find the damo source or documentation?
> >
> > You could use https://github.com/damonitor/damo and its README.md file.
> 
> Thank you so much for sharing.  I am trying to analyze the related contents
> in more detail to improve your DAMON.  I'll try to organize it a bit better
> and send you a patch.

Looking forward.


Thanks,
SJ

[...]

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[JaeJoon Jung]

On Mon, 22 Dec 2025 at 04:27, SeongJae Park <sj@kernel.org> wrote:
>
> On Sun, 21 Dec 2025 20:04:23 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
>
> > On Sun, 21 Dec 2025 at 17:12, SeongJae Park <sj@kernel.org> wrote:
> > >
> > > On Sun, 21 Dec 2025 11:42:43 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
> > >
> > > > On Fri, 19 Dec 2025 at 21:52, SeongJae Park <sj@kernel.org> wrote:
> > > > >
> > > > > On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > > > >
> > > > > > On 2025/12/16 07:16, SeongJae Park wrote:
> > > > > > > Hello Enze,
> > > > > > >
> > > > > > > On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > > [...]
> > > > > If runtime controls are essential, I think using DAMON sysfs
> > > > > interface or DAMON user-space tool is a better choice.
> > > >
> > > > I also think the current DAMON design structure is suitable for DAMON sysfs
> > > > and user-space tools.  DAMON sysfs can run multiple nr_ctxs, so I think it
> > > > would be a good idea to consolidate it into this.  As Enze mentioned, DAMON
> > > > was originally designed as a kernel loadable module,
> > >
> > > I don't recall where Enze mentioned so.  Could you please give me a pointer?
> >
> > Although Enze did not directly state this, His patch is a loadable module,
> > which implies that it was "designed as a kernel loadable module."
>
> Thanks for clarifying.  I understand you are saying Enze's prdm module is
> designed as a loadable module, while you are not saying about other parts of
> DAMON.
>
> >
> > >
> > > And I'm not sure based on what you are saying it was originally designed as a
> > > loadable module.  Maybe you are saying something before DAMON's mainline
> > > landing, but that's quite long ago and my memory management is not good.  Could
> > > you please add more contexts?
> > >
> > > > but I was curious as to
> > > > why it wasn't run that way.
> > >
> > > Maybe I could give you an answer if you could give me the context that I asked
> > > above.
> > >
> > > > When executing the damon_start(**ctxs,
> > > > nr_ctxs, exclusive)
> > > > function, nr_ctxs=1, exclusive=true is passed so that modules are currently
> > > > executed only one at a time.  Therefore, there is no point in running
> > > > DAMON
> > > > as a kernel module, since you are not running multiple modules simultaneously.
> > >
> > > I'm not following your point well.  Could you please elaborate your point?
> >
> > So far in my view, I have analyzed DAMON as follows:
> >
> > DAMON core  <---------> kernel module   <------> damo(user-space)
> > mm/damon/core.c         mm/damon/lru_sort.c
> > mm/damon/vaddr.c        mm/damon/reclaim.c
> > mm/damon/paddr.c        samples/damon/*.c
> > mm/damon/sysfs.c
> >
> > Above, lru_sort and reclaim are DAMON core characteristics, but they have
> > a kernel module structure because they are executed with module_init().
> > I personally think this is inappropriate.
>
> Could you please further clarify why you think it is inappropriate?
>
> > Additionally, currently, DAMON is
> > executed only once at a time according to the exclusive=true condition
> > when damon_start() is called.  In this structure, I believe that the meaning
> > of "kernel loadable module"  is non-existent.
>
> I have to say I still don't get your points.  More elaboration would be nice.

To summarize the Damon I have analyzed so far,

DAMON core  <---------------> DAMON kernel module
| mm/damon/core.c               + mm/damon/lru_sort.c (schemes setting)
| mm/damon/vaddr.c              + mm/damon/reclaim.c (quota, filter)
| mm/damon/paddr.c              + samples/damon/*.c (using samples)
| mm/damon/sysfs.c
            |
        /sys/kernel/mm/damon/admin
            |
            +--------------------------> open/read(get)/write(set)/close
                                               (user-space system call)

The DAMON kernel module above is a sample that sets some parameters of
DAMON.  I think it's better to use damon/sysfs since all of this can be
done in damon/sysfs.  I am continuing to analyze this.  If any
improvements are found, I'll send you a patch.

Thanks,
JaeJoon

>
> >
> > >
> > > > I'm doing some more research into why we run modules with exclusive=true.
> > >
> > > Hoplefully commit 8b9b0d335a34 ("mm/damon/core: allow non-exclusive DAMON
> > > start/stop") will give you more contexts.
> > >
> > > To summarize again, the intention is to avoid kdamonds interrupting each
> > > other's access checks.  For example, suppose the DAMON context for
> > > DAMON_RECLAIM and another one (could be created by DAMON sysfs interface users
> > > or other DAMON modules, say, DAMON_STAT) are running concurrently.  And if
> > > those pick a same page as access check sampling target, their finding of the
> > > access on the page depend on a race condition.  To avoid such a case, DAMON
> > > modules call damon_start() with exclusive argument set.
> > >
> > > Maybe this is unclearly documented.  I will recheck the documentation and
> > > improve it to make this more clear.  If you find the rooms to improve and have
> > > ideas for the improvements, please feel free to send patches.
> > >
> > > > One more thing I would like to add is that I think it would be less
> > > > confusing
> > > > to move lru_sort and reclaim to the samples/damon/ path.
> > >
> > > No, I don't think so.  Those are for real world products, not for samples.
> > >
> > > > And it would
> > > > be
> > > > a good idea to organize the core sources toward
> > > > mm/damon/modules-common.c source.
> > >
> > > I don't find exactly what kind of reorganization you mean.  But I agree there
> > > could be rooms to improve in terms of the files and code organization.  Any
> > > suggestion is welcome.
> > >
> > > [...]
> > > > > > Finally, I would like to add that designing prdm with an extremely
> > > > > > simple workflow -- load the module, set the target PIDs, and enable the
> > > > > > switch -- will contribute to the promotion of DAMON, allowing a broader
> > > > > > user base to benefit from the DAMON system.
> > > > >
> > > > > That workflow is definitely much easier than directly using DAMON sysfs
> > > > > interface.  But, for the reason we have DAMON user-space tool.  Using it, the
> > > > > workflow can also be as simple as prdm, like below.
> > > > >
> > > > >    # damo start $TARGET_PID --damos_action pageout --damos_access_rate 0% 0% --damos_age 2m max
> > > >
> > > > Where can I find the damo source or documentation?
> > >
> > > You could use https://github.com/damonitor/damo and its README.md file.
> >
> > Thank you so much for sharing.  I am trying to analyze the related contents
> > in more detail to improve your DAMON.  I'll try to organize it a bit better
> > and send you a patch.
>
> Looking forward.
>
>
> Thanks,
> SJ
>
> [...]

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[SeongJae Park]

On Tue, 23 Dec 2025 05:57:55 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:

> On Mon, 22 Dec 2025 at 04:27, SeongJae Park <sj@kernel.org> wrote:
> > On Sun, 21 Dec 2025 20:04:23 +0900 JaeJoon Jung <rgbi3307@gmail.com> wrote:
[...]
> > > So far in my view, I have analyzed DAMON as follows:
> > >
> > > DAMON core  <---------> kernel module   <------> damo(user-space)
> > > mm/damon/core.c         mm/damon/lru_sort.c
> > > mm/damon/vaddr.c        mm/damon/reclaim.c
> > > mm/damon/paddr.c        samples/damon/*.c
> > > mm/damon/sysfs.c
> > >
> > > Above, lru_sort and reclaim are DAMON core characteristics, but they have
> > > a kernel module structure because they are executed with module_init().
> > > I personally think this is inappropriate.
> >
> > Could you please further clarify why you think it is inappropriate?
> >
> > > Additionally, currently, DAMON is
> > > executed only once at a time according to the exclusive=true condition
> > > when damon_start() is called.  In this structure, I believe that the meaning
> > > of "kernel loadable module"  is non-existent.
> >
> > I have to say I still don't get your points.  More elaboration would be nice.
> 
> To summarize the Damon I have analyzed so far,
> 
> DAMON core  <---------------> DAMON kernel module
> | mm/damon/core.c               + mm/damon/lru_sort.c (schemes setting)
> | mm/damon/vaddr.c              + mm/damon/reclaim.c (quota, filter)
> | mm/damon/paddr.c              + samples/damon/*.c (using samples)
> | mm/damon/sysfs.c
>             |
>         /sys/kernel/mm/damon/admin
>             |
>             +--------------------------> open/read(get)/write(set)/close
>                                                (user-space system call)

Nice analysis.  Please consider further referring to the 'overall
architectures' section of the design doc [1].

> 
> The DAMON kernel module above is a sample that sets some parameters of
> DAMON.  I think it's better to use damon/sysfs since all of this can be
> done in damon/sysfs.

I agree using DAMON sysfs only can be better for some use cases.  But nothing
fits all.  Hence we intentionally provide both general purpose user interface
module (DAMON sysfs interface) and special-purpose modules.  Please refer to
the 'modules' section of the design doc [1] for more details.

> I am continuing to analyze this.  If any
> improvements are found, I'll send you a patch.

Looking forward!

[1] https://origin.kernel.org/doc/html/latest/mm/damon/design.html


Thanks,
SJ

[...]

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[Enze Li]

Hi SJ,

I appreciate you taking the time to provide such a detailed reply.  I
have a few more questions.  Please see below.

On 12/19/25 7:46 PM, SeongJae Park wrote:
> On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
> 
>> On 2025/12/16 07:16, SeongJae Park wrote:
>>> Hello Enze,
>>>
>>> On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
>>>
>>>> This patchset makes DAMON's advanced memory management accessible to a
>>>> broader range of users through two complementary enhancements.  First,
>>>> it exports the necessary DAMON core symbols to enable building loadable
>>>> kernel modules.  Building on this foundation, it then introduces the
>>>> 'prdm' module, which extends the concept from the DAMON sample code
>>>> (prcl.c) into a production-ready, user-friendly tool.
>>>>
>>>> The key strength of this module is its out-of-the-box simplicity: by
>>>> simply specifying the PIDs of target processes and enabling the module,
>>>> users can concurrently monitor memory access patterns across multiple
>>>> processes and trigger proactive reclamation automatically.  This
>>>> significantly lowers the barrier to using DAMON, allowing system
>>>> administrators and regular users without deep kernel expertise to easily
>>>> apply sophisticated memory optimization.
>>>

<...>

>>
>> Before developing prdm, I had considered implementing the same
>> functionality based on DAMON_RECLAIM.  However, I gradually realized
>> this would make DAMON_RECLAIM overly complex and less
>> user-friendly—especially given its existing module-specific exported
>> interfaces, which could confuse users.  This approach would create
>> significant barriers to promoting wider DAMON adoption.  Consequently,
>> building upon the prcl sample became the preferred choice.
> 
> I agree DAMON_RECLAIM already have no small number of parameters, and adding
> more may make it look even more complex.  But, users may use only parameters
> that really need to be set for their real use case.
> 
> For example, if we implement virtual address spaces mode in DAMON_RECLAIM, I
> think we can simply add target_pid parameter that works very same to that of
> prdm.  If it is unset, DAMON_RECLAIM works in the physical address mode.  If it
> is set, it works in the virtual address mode.  Adding just one more parameter
> that doesn't break old usage doesn't seem that complex change to me, at least
> in terms of the user experience.

This should be viable, though it will take a moderate amount of extra
time to develop.

> 
> As I mentioned above, yet another example would be using
> DAMOS_FILTER_TYPE_MEMCG.  For this, we may be able to add a parameter for
> describing the memcg of critical processes.  Again, adding just one more
> parameter that doesn't affect old usages doesn't seem too complex changes to
> me, at least in terms of the user experience.
> 
> Meanwhile, I agree adding a new simpler module could make it easy for new
> users.  But, I concern if having two modules for DAMON-based reclamation will
> make users get difficulty at finding the correct one for their usage, since
> they may now need to compare two modules.

Indeed, you're right.  From an architectural perspective, having two
modules forces users to spend time distinguishing between them, which
can cause confusion.

<...>

>>>
>>> And, even more importantly, why it should be a loadable module rather than a
>>> static module?  Do you have a specific use case that requires it to be a
>>> loadable module?
>>
>> Yes, loadability is crucial for operational flexibility in practical
>> production environments.  Beyond some obvious advantages, I would like
>> to highlight a key scenario: system administrators can load the prdm
>> module upon detecting memory pressure and unload it immediately after
>> reclamation is complete, thereby eliminating any overhead during normal
>> operation.
> 
> I agree always having prdm in kernel is an overhead.  But, I think the
> overhead is not meaningfully big.  Also, as I mentioned above, my intended use
> cases of DAMON modules is for cases that willing to simply always use the
> modules.  If runtime controls are essential, I think using DAMON sysfs
> interface or DAMON user-space tool is a better choice.

The prdm was developed based on samples/damon/prcl.c.  Would it be an
acceptable modification to port the multi-process support feature to
prcl?  Does that make sense to you?

> 
> Someone might argue DAMON sysfs interface is unnecessarily big compared to
> prdm.  But, I have to ask again in the case.  Does the overhead really
> meaningfully big for a real world use case?
> 
>> Furthermore, it supports zero-downtime updates, meaning that
>> improvements targeting prdm can be deployed via a simple module reload,
>> avoiding costly system reboots.
> 
> So I'm not really convinced at needs of prdm module at the moment.  But I agree
> your above point is a good example advantage of loadable modules.  Also there
> were private requests to support loadable DAMON modules.  No one among those
> were for real production use case, and I understand you are also doing this
> work for imaginable use cases, not your real products.  Please correct me if
> I'm wrong.  But as the request is repeated, if you willing to convert existing
> DAMON modules to support loadable modules build and expose required DAMON
> functions for that, at least I wouldn't oppose.

Thank you for your feedback.  I would like to try it out.

Best Regards,
Enze

<...>

Re: [PATCH 0/2] mm/damon: export symbols and introduce prdm module

[SeongJae Park]

On Mon, 22 Dec 2025 15:08:01 +0800 Enze Li <lienze@kylinos.cn> wrote:

> Hi SJ,
> 
> I appreciate you taking the time to provide such a detailed reply.  I
> have a few more questions.  Please see below.
> 
> On 12/19/25 7:46 PM, SeongJae Park wrote:
> > On Thu, 18 Dec 2025 21:46:37 +0800 Enze Li <lienze@kylinos.cn> wrote:
> > 
> >> On 2025/12/16 07:16, SeongJae Park wrote:
> >>> Hello Enze,
> >>>
> >>> On Mon, 15 Dec 2025 22:20:55 +0800 Enze Li <lienze@kylinos.cn> wrote:
> >>>
> >>>> This patchset makes DAMON's advanced memory management accessible to a
> >>>> broader range of users through two complementary enhancements.  First,
> >>>> it exports the necessary DAMON core symbols to enable building loadable
> >>>> kernel modules.  Building on this foundation, it then introduces the
> >>>> 'prdm' module, which extends the concept from the DAMON sample code
> >>>> (prcl.c) into a production-ready, user-friendly tool.
> >>>>
> >>>> The key strength of this module is its out-of-the-box simplicity: by
> >>>> simply specifying the PIDs of target processes and enabling the module,
> >>>> users can concurrently monitor memory access patterns across multiple
> >>>> processes and trigger proactive reclamation automatically.  This
> >>>> significantly lowers the barrier to using DAMON, allowing system
> >>>> administrators and regular users without deep kernel expertise to easily
> >>>> apply sophisticated memory optimization.
> >>>
> 
> <...>
> 
> >>
> >> Before developing prdm, I had considered implementing the same
> >> functionality based on DAMON_RECLAIM.  However, I gradually realized
> >> this would make DAMON_RECLAIM overly complex and less
> >> user-friendly—especially given its existing module-specific exported
> >> interfaces, which could confuse users.  This approach would create
> >> significant barriers to promoting wider DAMON adoption.  Consequently,
> >> building upon the prcl sample became the preferred choice.
> > 
> > I agree DAMON_RECLAIM already have no small number of parameters, and adding
> > more may make it look even more complex.  But, users may use only parameters
> > that really need to be set for their real use case.
> > 
> > For example, if we implement virtual address spaces mode in DAMON_RECLAIM, I
> > think we can simply add target_pid parameter that works very same to that of
> > prdm.  If it is unset, DAMON_RECLAIM works in the physical address mode.  If it
> > is set, it works in the virtual address mode.  Adding just one more parameter
> > that doesn't break old usage doesn't seem that complex change to me, at least
> > in terms of the user experience.
> 
> This should be viable, though it will take a moderate amount of extra
> time to develop.
> 
> > 
> > As I mentioned above, yet another example would be using
> > DAMOS_FILTER_TYPE_MEMCG.  For this, we may be able to add a parameter for
> > describing the memcg of critical processes.  Again, adding just one more
> > parameter that doesn't affect old usages doesn't seem too complex changes to
> > me, at least in terms of the user experience.
> > 
> > Meanwhile, I agree adding a new simpler module could make it easy for new
> > users.  But, I concern if having two modules for DAMON-based reclamation will
> > make users get difficulty at finding the correct one for their usage, since
> > they may now need to compare two modules.
> 
> Indeed, you're right.  From an architectural perspective, having two
> modules forces users to spend time distinguishing between them, which
> can cause confusion.
> 
> <...>
> 
> >>>
> >>> And, even more importantly, why it should be a loadable module rather than a
> >>> static module?  Do you have a specific use case that requires it to be a
> >>> loadable module?
> >>
> >> Yes, loadability is crucial for operational flexibility in practical
> >> production environments.  Beyond some obvious advantages, I would like
> >> to highlight a key scenario: system administrators can load the prdm
> >> module upon detecting memory pressure and unload it immediately after
> >> reclamation is complete, thereby eliminating any overhead during normal
> >> operation.
> > 
> > I agree always having prdm in kernel is an overhead.  But, I think the
> > overhead is not meaningfully big.  Also, as I mentioned above, my intended use
> > cases of DAMON modules is for cases that willing to simply always use the
> > modules.  If runtime controls are essential, I think using DAMON sysfs
> > interface or DAMON user-space tool is a better choice.
> 
> The prdm was developed based on samples/damon/prcl.c.  Would it be an
> acceptable modification to port the multi-process support feature to
> prcl?  Does that make sense to you?

Yes, that makes sense.

Please note that the purpose of sample modules is not to be used in the real
world products, but just explaining people how DAMON API can be used.  In this
case, I think multi-process support feature can let people better understand
how they can use DAMON for multiple processes, so I think that's good to add.

> 
> > 
> > Someone might argue DAMON sysfs interface is unnecessarily big compared to
> > prdm.  But, I have to ask again in the case.  Does the overhead really
> > meaningfully big for a real world use case?
> > 
> >> Furthermore, it supports zero-downtime updates, meaning that
> >> improvements targeting prdm can be deployed via a simple module reload,
> >> avoiding costly system reboots.
> > 
> > So I'm not really convinced at needs of prdm module at the moment.  But I agree
> > your above point is a good example advantage of loadable modules.  Also there
> > were private requests to support loadable DAMON modules.  No one among those
> > were for real production use case, and I understand you are also doing this
> > work for imaginable use cases, not your real products.  Please correct me if
> > I'm wrong.  But as the request is repeated, if you willing to convert existing
> > DAMON modules to support loadable modules build and expose required DAMON
> > functions for that, at least I wouldn't oppose.
> 
> Thank you for your feedback.  I would like to try it out.

Looking forward!

Please note that there could be objection from others, though.  In the case,
unless you have real world usage of loadable DAMON modules, I may have to agree
to the others' concerns, like I had to do so [1] last time.

[1] https://lore.kernel.org/damon/20231205172307.2310-1-sj@kernel.org/


Thanks,
SJ

[...]