To use DAMON for monitoring access patterns of the system, users should
manually start DAMON via DAMON sysfs ABI with a number of parameters for
specifying the monitoring target address space, address ranges, and
monitoring intervals. After that, users should also wait until desired
amount of time data is captured into DAMON's monitoring results. It is
bothersome and take a long time to be practical for access monitoring on
large fleet level production environments.
For access-aware system operations use cases like proactive cold memory
reclamation, similar problems existed. We we solved those by
introducing dedicated static kernel modules such as DAMON_RECLAIM.
Implement such static kernel module for access monitoring, namely
DAMON_STAT. It monitors the entire physical address space with
auto-tuned monitoring intervals. The auto-tuning is set to capture 4 %
of observable access events in each snapshot while keeping the sampling
intervals 5 milliseconds in minimum and 10 seconds in maximum. From
a few production environments, we confirmed this setup provides high
quality monitoring results with minimum overheads. The module therefore
receives only one user input, whether to enable or disable it. It can
be set on build or boot time via build configuration or kernel boot
command line. It can also be overridden at runtime.
Note that this commit only implements the DAMON control part of the
module. Users could get the monitoring results via
damon:damon_aggregated tracepoint, but that's of course not the
recommended way. Following commits will implement convenient and
optimized ways for serving the monitoring results to users.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
mm/damon/Kconfig | 16 ++++++
mm/damon/Makefile | 1 +
mm/damon/stat.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 155 insertions(+)
create mode 100644 mm/damon/stat.c
diff --git a/mm/damon/Kconfig b/mm/damon/Kconfig
index 551745df011b..9f482e3adc67 100644
--- a/mm/damon/Kconfig
+++ b/mm/damon/Kconfig
@@ -95,4 +95,20 @@ config DAMON_LRU_SORT
protect frequently accessed (hot) pages while rarely accessed (cold)
pages reclaimed first under memory pressure.
+config DAMON_STAT
+ bool "Build data access monitoring stat (DAMON_STAT)"
+ depends on DAMON_PADDR
+ help
+ This builds the DAMON-based access monitoring statistics subsystem.
+ It runs DAMON and expose access monitoring results in simple stat
+ metrics.
+
+config DAMON_STAT_ENABLED_DEFAULT
+ bool "Enable DAMON_STAT by default"
+ depends on DAMON_PADDR
+ default DAMON_STAT
+ help
+ Whether to enable DAMON_STAT by default. Users can disable it in
+ boot or runtime using its 'enabled' parameter.
+
endmenu
diff --git a/mm/damon/Makefile b/mm/damon/Makefile
index 8b49012ba8c3..d8d6bf5f8bff 100644
--- a/mm/damon/Makefile
+++ b/mm/damon/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DAMON_PADDR) += ops-common.o paddr.o
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
diff --git a/mm/damon/stat.c b/mm/damon/stat.c
new file mode 100644
index 000000000000..852848ce844e
--- /dev/null
+++ b/mm/damon/stat.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Shows data access monitoring resutls in simple metrics.
+ */
+
+#define pr_fmt(fmt) "damon-stat: " fmt
+
+#include <linux/damon.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sort.h>
+
+#ifdef MODULE_PARAM_PREFIX
+#undef MODULE_PARAM_PREFIX
+#endif
+#define MODULE_PARAM_PREFIX "damon_stat."
+
+static int damon_stat_enabled_store(
+ const char *val, const struct kernel_param *kp);
+
+static const struct kernel_param_ops enabled_param_ops = {
+ .set = damon_stat_enabled_store,
+ .get = param_get_bool,
+};
+
+static bool enabled __read_mostly = CONFIG_DAMON_STAT_ENABLED_DEFAULT;
+module_param_cb(enabled, &enabled_param_ops, &enabled, 0600);
+MODULE_PARM_DESC(enabled, "Enable of disable DAMON_STAT");
+
+static struct damon_ctx *damon_stat_context;
+
+static struct damon_ctx *damon_stat_build_ctx(void)
+{
+ struct damon_ctx *ctx;
+ struct damon_attrs attrs;
+ struct damon_target *target;
+ unsigned long start = 0, end = 0;
+
+ ctx = damon_new_ctx();
+ if (!ctx)
+ return NULL;
+ attrs = (struct damon_attrs) {
+ .sample_interval = 5 * USEC_PER_MSEC,
+ .aggr_interval = 100 * USEC_PER_MSEC,
+ .ops_update_interval = 60 * USEC_PER_MSEC * MSEC_PER_SEC,
+ .min_nr_regions = 10,
+ .max_nr_regions = 1000,
+ };
+ /*
+ * auto-tune sampling and aggregation interval aiming 4% DAMON-observed
+ * accesses ratio, keeping sampling interval in [5ms, 10s] range.
+ */
+ attrs.intervals_goal = (struct damon_intervals_goal) {
+ .access_bp = 400, .aggrs = 3,
+ .min_sample_us = 5000, .max_sample_us = 10000000,
+ };
+ if (damon_set_attrs(ctx, &attrs))
+ goto free_out;
+
+ /*
+ * auto-tune sampling and aggregation interval aiming 4% DAMON-observed
+ * accesses ratio, keeping sampling interval in [5ms, 10s] range.
+ */
+ ctx->attrs.intervals_goal = (struct damon_intervals_goal) {
+ .access_bp = 400, .aggrs = 3,
+ .min_sample_us = 5000, .max_sample_us = 10000000,
+ };
+ if (damon_select_ops(ctx, DAMON_OPS_PADDR))
+ goto free_out;
+
+ target = damon_new_target();
+ if (!target)
+ goto free_out;
+ damon_add_target(ctx, target);
+ if (damon_set_region_biggest_system_ram_default(target, &start, &end))
+ goto free_out;
+ return ctx;
+free_out:
+ damon_destroy_ctx(ctx);
+ return NULL;
+}
+
+static int damon_stat_start(void)
+{
+ damon_stat_context = damon_stat_build_ctx();
+ if (!damon_stat_context)
+ return -ENOMEM;
+ return damon_start(&damon_stat_context, 1, true);
+}
+
+static void damon_stat_stop(void)
+{
+ damon_stop(&damon_stat_context, 1);
+ damon_destroy_ctx(damon_stat_context);
+}
+
+static bool damon_stat_init_called;
+
+static int damon_stat_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 (is_enabled == enabled)
+ return 0;
+
+ if (!damon_stat_init_called)
+ /*
+ * probably called from command line parsing (parse_args()).
+ * Cannot call damon_new_ctx(). Let damon_stat_init() handle.
+ */
+ return 0;
+
+ if (enabled)
+ return damon_stat_start();
+ damon_stat_stop();
+ return 0;
+}
+
+static int __init damon_stat_init(void)
+{
+ int err = 0;
+
+ damon_stat_init_called = true;
+
+ /* probably set via command line */
+ if (enabled)
+ err = damon_stat_start();
+ return err;
+}
+
+module_init(damon_stat_init);
--
2.39.5On Wed, 4 Jun 2025 11:31:24 -0700 SeongJae Park <sj@kernel.org> wrote:
> To use DAMON for monitoring access patterns of the system, users should
> manually start DAMON via DAMON sysfs ABI with a number of parameters for
> specifying the monitoring target address space, address ranges, and
> monitoring intervals. After that, users should also wait until desired
> amount of time data is captured into DAMON's monitoring results. It is
> bothersome and take a long time to be practical for access monitoring on
> large fleet level production environments.
>
> For access-aware system operations use cases like proactive cold memory
> reclamation, similar problems existed. We we solved those by
> introducing dedicated static kernel modules such as DAMON_RECLAIM.
>
> Implement such static kernel module for access monitoring, namely
> DAMON_STAT. It monitors the entire physical address space with
> auto-tuned monitoring intervals. The auto-tuning is set to capture 4 %
> of observable access events in each snapshot while keeping the sampling
> intervals 5 milliseconds in minimum and 10 seconds in maximum. From
> a few production environments, we confirmed this setup provides high
> quality monitoring results with minimum overheads. The module therefore
> receives only one user input, whether to enable or disable it. It can
> be set on build or boot time via build configuration or kernel boot
> command line. It can also be overridden at runtime.
>
> Note that this commit only implements the DAMON control part of the
> module. Users could get the monitoring results via
> damon:damon_aggregated tracepoint, but that's of course not the
> recommended way. Following commits will implement convenient and
> optimized ways for serving the monitoring results to users.
>
> Signed-off-by: SeongJae Park <sj@kernel.org>
> ---
Hi SJ, thank you for this patch! I have been looking forward to it : -)
I had a few questions about the init function:
[...snip...]
> +static int damon_stat_start(void)
> +{
> + damon_stat_context = damon_stat_build_ctx();
> + if (!damon_stat_context)
> + return -ENOMEM;
> + return damon_start(&damon_stat_context, 1, true);
> +}
> +
> +static void damon_stat_stop(void)
> +{
> + damon_stop(&damon_stat_context, 1);
> + damon_destroy_ctx(damon_stat_context);
> +}
> +
> +static bool damon_stat_init_called;
> +
> +static int damon_stat_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 (is_enabled == enabled)
> + return 0;
> +
> + if (!damon_stat_init_called)
> + /*
> + * probably called from command line parsing (parse_args()).
> + * Cannot call damon_new_ctx(). Let damon_stat_init() handle.
> + */
> + return 0;
I was hoping you could educate me about how damon_stat_init_called works here.
I think my confusion comes from my lack of knowledge about kernel modules : -)
In the cover letter, you wrote that DAMON_STAT is a static kernel module.
My understanding was that this would mean damon_stat_init would always be
called, so I was wondering under what condition it would not be initialized.
I see the comment you wrote above, but was still a little bit confused.
Also, should we perhaps call damon_stat_init() if !damon_stat_init_called?
That way, the first caller would just eat up the time it takes to run
damon_stat_start().
One other thought I have is that if this config checks for whether
damon_stat_init was called, this can be moved to the beginning of the function
before the other checks are run, but that is just my thought : -) Feel free
to keep the input check first, since having this at the beginning of the
function would mean incorrect inputs would be silently ignored.
Thank you SJ! I hope you have a great day!
Joshua
> + if (enabled)
> + return damon_stat_start();
> + damon_stat_stop();
> + return 0;
> +}
> +
> +static int __init damon_stat_init(void)
> +{
> + int err = 0;
> +
> + damon_stat_init_called = true;
> +
> + /* probably set via command line */
> + if (enabled)
> + err = damon_stat_start();
> + return err;
> +}
> +
> +module_init(damon_stat_init);
> --
> 2.39.5
On Thu, 5 Jun 2025 08:25:07 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
> On Wed, 4 Jun 2025 11:31:24 -0700 SeongJae Park <sj@kernel.org> wrote:
[...]
> Hi SJ, thank you for this patch! I have been looking forward to it : -)
> I had a few questions about the init function:
Hi Joshua, I'm more than happy to get your questions :)
>
> [...snip...]
>
> > +static int damon_stat_start(void)
> > +{
> > + damon_stat_context = damon_stat_build_ctx();
> > + if (!damon_stat_context)
> > + return -ENOMEM;
> > + return damon_start(&damon_stat_context, 1, true);
> > +}
> > +
> > +static void damon_stat_stop(void)
> > +{
> > + damon_stop(&damon_stat_context, 1);
> > + damon_destroy_ctx(damon_stat_context);
> > +}
> > +
> > +static bool damon_stat_init_called;
> > +
> > +static int damon_stat_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 (is_enabled == enabled)
> > + return 0;
> > +
> > + if (!damon_stat_init_called)
> > + /*
> > + * probably called from command line parsing (parse_args()).
> > + * Cannot call damon_new_ctx(). Let damon_stat_init() handle.
> > + */
> > + return 0;
>
> I was hoping you could educate me about how damon_stat_init_called works here.
> I think my confusion comes from my lack of knowledge about kernel modules : -)
> In the cover letter, you wrote that DAMON_STAT is a static kernel module.
> My understanding was that this would mean damon_stat_init would always be
> called,
To my understanding, the function is called back only when the parameteer value
is being changed. Such changes could be made in runtime via parameter files,
and in boot time via the kernel command line. If there is not kernel command
line for setting the parameter, this callback function is not called.
> so I was wondering under what condition it would not be initialized.
The enabled parameter value is initialized at build time, based on
CONFIG_DAMON_STAT_ENABLED_DEFAULT. So, the parameter value will always be
initialized.
> I see the comment you wrote above, but was still a little bit confused.
The kernel command line parameters parsing is called in pretty early stage of
the bootup, before slab is ready. Hence, if enabled parmeter is set by the
kernel command line, damon_stat_enabled_store() is called in the early stage,
and fails from damon_stat_start(), since it needs slab, to initialize DAMON
contexts. For more details of such failure, you could refer to a previous
issue report[1].
Meanwhile, damon_stat_init() and module init functions are called later, when
slab is ready. We therefore check the case, and defer real handling of enabled
to damon_stat_init() in the case.
Thank you for this question, I find the comment has rooms to improve. I'll try
to make this better documented or easier to read.
>
> Also, should we perhaps call damon_stat_init() if !damon_stat_init_called?
> That way, the first caller would just eat up the time it takes to run
> damon_stat_start().
damon_stat_init() is a module init function, and hence it will be called in
boot time, regardless of enabled parameter setup on kernel command line. In
other words, it will be always invoked once, with !damon_stat_init_called. And
it will call damon_stat_start(), unless enabled is unset via
CONFIG_DAMON_STAT_ENABLED_DEFAULT or kernel command line.
So, the current implementation is working as you suggested, to my
understanding. Please let me know if I'm missing something.
>
> One other thought I have is that if this config checks for whether
> damon_stat_init was called, this can be moved to the beginning of the function
> before the other checks are run, but that is just my thought : -) Feel free
> to keep the input check first, since having this at the beginning of the
> function would mean incorrect inputs would be silently ignored.
In the kernel command line based parameter setup scenario, later
damon_stat_init() call should see the updated 'enabled' variable value. Hence,
the user input value check should be done here, regardless of if this is called
before or after damon_stat_init().
So I find no needs to change the code for now. Nonetheless, I believe this
code has many rooms to improve, and I'm always getting more than glad to get
this kind of improvement ideas. Thank you, Joshua. Please feel free to let me
know if you get another idea later.
I hope I answered your questions, but please let me know if I'm missing
something!
>
> Thank you SJ! I hope you have a great day!
You too. Friday is coming!
[1] https://lore.kernel.org/linux-mm/20220604192222.1488-1-sj@kernel.org/
Thanks,
SJ
[...]
On Thu, 5 Jun 2025 09:11:29 -0700 SeongJae Park <sj@kernel.org> wrote:
> On Thu, 5 Jun 2025 08:25:07 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
>
> > On Wed, 4 Jun 2025 11:31:24 -0700 SeongJae Park <sj@kernel.org> wrote:
> [...]
> > Hi SJ, thank you for this patch! I have been looking forward to it : -)
> > I had a few questions about the init function:
>
> Hi Joshua, I'm more than happy to get your questions :)
>
> >
> > [...snip...]
> >
> > > +static int damon_stat_start(void)
> > > +{
> > > + damon_stat_context = damon_stat_build_ctx();
> > > + if (!damon_stat_context)
> > > + return -ENOMEM;
> > > + return damon_start(&damon_stat_context, 1, true);
> > > +}
> > > +
> > > +static void damon_stat_stop(void)
> > > +{
> > > + damon_stop(&damon_stat_context, 1);
> > > + damon_destroy_ctx(damon_stat_context);
> > > +}
> > > +
> > > +static bool damon_stat_init_called;
> > > +
> > > +static int damon_stat_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 (is_enabled == enabled)
> > > + return 0;
> > > +
> > > + if (!damon_stat_init_called)
> > > + /*
> > > + * probably called from command line parsing (parse_args()).
> > > + * Cannot call damon_new_ctx(). Let damon_stat_init() handle.
> > > + */
> > > + return 0;
> >
> > I was hoping you could educate me about how damon_stat_init_called works here.
> > I think my confusion comes from my lack of knowledge about kernel modules : -)
> > In the cover letter, you wrote that DAMON_STAT is a static kernel module.
> > My understanding was that this would mean damon_stat_init would always be
> > called,
>
> To my understanding, the function is called back only when the parameteer value
> is being changed. Such changes could be made in runtime via parameter files,
> and in boot time via the kernel command line. If there is not kernel command
> line for setting the parameter, this callback function is not called.
>
> > so I was wondering under what condition it would not be initialized.
>
> The enabled parameter value is initialized at build time, based on
> CONFIG_DAMON_STAT_ENABLED_DEFAULT. So, the parameter value will always be
> initialized.
>
> > I see the comment you wrote above, but was still a little bit confused.
>
> The kernel command line parameters parsing is called in pretty early stage of
> the bootup, before slab is ready. Hence, if enabled parmeter is set by the
> kernel command line, damon_stat_enabled_store() is called in the early stage,
> and fails from damon_stat_start(), since it needs slab, to initialize DAMON
> contexts. For more details of such failure, you could refer to a previous
> issue report[1].
>
> Meanwhile, damon_stat_init() and module init functions are called later, when
> slab is ready. We therefore check the case, and defer real handling of enabled
> to damon_stat_init() in the case.
>
> Thank you for this question, I find the comment has rooms to improve. I'll try
> to make this better documented or easier to read.
I see, I think it makes more sense to me now. Thank you for explaining this, SJ!
I think my confusion came from my lack of knowledge. Please do not feel the need
to update the comment on this section, if you feel it is already enough : -)
> > Also, should we perhaps call damon_stat_init() if !damon_stat_init_called?
> > That way, the first caller would just eat up the time it takes to run
> > damon_stat_start().
>
> damon_stat_init() is a module init function, and hence it will be called in
> boot time, regardless of enabled parameter setup on kernel command line. In
> other words, it will be always invoked once, with !damon_stat_init_called. And
> it will call damon_stat_start(), unless enabled is unset via
> CONFIG_DAMON_STAT_ENABLED_DEFAULT or kernel command line.
>
> So, the current implementation is working as you suggested, to my
> understanding. Please let me know if I'm missing something.
> >
> > One other thought I have is that if this config checks for whether
> > damon_stat_init was called, this can be moved to the beginning of the function
> > before the other checks are run, but that is just my thought : -) Feel free
> > to keep the input check first, since having this at the beginning of the
> > function would mean incorrect inputs would be silently ignored.
>
> In the kernel command line based parameter setup scenario, later
> damon_stat_init() call should see the updated 'enabled' variable value. Hence,
> the user input value check should be done here, regardless of if this is called
> before or after damon_stat_init().
>
> So I find no needs to change the code for now. Nonetheless, I believe this
> code has many rooms to improve, and I'm always getting more than glad to get
> this kind of improvement ideas. Thank you, Joshua. Please feel free to let me
> know if you get another idea later.
>
> I hope I answered your questions, but please let me know if I'm missing
> something!
Thanks SJ, it all makes a lot more sense now. Thank you for taking the time
to explain things!
> >
> > Thank you SJ! I hope you have a great day!
>
> You too. Friday is coming!
>
> [1] https://lore.kernel.org/linux-mm/20220604192222.1488-1-sj@kernel.org/
>
>
> Thanks,
> SJ
>
> [...]
Sent using hkml (https://github.com/sjp38/hackermail)
On Wed, 4 Jun 2025 11:31:24 -0700 SeongJae Park <sj@kernel.org> wrote:
[...]
> --- /dev/null
> +++ b/mm/damon/stat.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Shows data access monitoring resutls in simple metrics.
> + */
> +
> +#define pr_fmt(fmt) "damon-stat: " fmt
> +
> +#include <linux/damon.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/sort.h>
> +
> +#ifdef MODULE_PARAM_PREFIX
> +#undef MODULE_PARAM_PREFIX
> +#endif
> +#define MODULE_PARAM_PREFIX "damon_stat."
> +
> +static int damon_stat_enabled_store(
> + const char *val, const struct kernel_param *kp);
> +
> +static const struct kernel_param_ops enabled_param_ops = {
> + .set = damon_stat_enabled_store,
> + .get = param_get_bool,
> +};
> +
> +static bool enabled __read_mostly = CONFIG_DAMON_STAT_ENABLED_DEFAULT;
Oops, I forgot using IS_ENABLED() here. Andrew, could you please add below
fixup?
Thanks,
SJ
===== >8 =====
From bc2a2c580f6f89f3f7d4f92c2bde3f4a4fac3409 Mon Sep 17 00:00:00 2001
From: SeongJae Park <sj@kernel.org>
Date: Wed, 4 Jun 2025 13:48:30 -0700
Subject: [PATCH] mm/damon/stat: use IS_ENABLED() for enabled initial value
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The initial value of enabled parameter is set as
CONFIG_DAMON_STAT_ENABLED_DEFAULT, so get below build error when the
config is not enabled. Fix it using IS_ENABLED().
mm/damon/stat.c:27:37: error: ‘CONFIG_DAMON_STAT_ENABLED_DEFAULT’ undeclared here (not in a function)
27 | static bool enabled __read_mostly = CONFIG_DAMON_STAT_ENABLED_DEFAULT;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: SeongJae Park <sj@kernel.org>
---
mm/damon/stat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/damon/stat.c b/mm/damon/stat.c
index 7ef13ea22221..3686f67befc3 100644
--- a/mm/damon/stat.c
+++ b/mm/damon/stat.c
@@ -24,7 +24,8 @@ static const struct kernel_param_ops enabled_param_ops = {
.get = param_get_bool,
};
-static bool enabled __read_mostly = CONFIG_DAMON_STAT_ENABLED_DEFAULT;
+static bool enabled __read_mostly = IS_ENABLED(
+ CONFIG_DAMON_STAT_ENABLED_DEFAULT);
module_param_cb(enabled, &enabled_param_ops, &enabled, 0600);
MODULE_PARM_DESC(enabled, "Enable of disable DAMON_STAT");
--
2.39.5
© 2016 - 2025 Red Hat, Inc.