In module DAMON_RECLAIM and DAMON_LRU_SORT, the damon_ctx is
independent of the core, necessitating dedicated addr_unit
integration for these features.
Additionally, if the input monitor_region_start and monitor_region_end
are both 0 while addr_unit is set to a non-zero valuethe default
system RAM range should be divided by addr_unit.
Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com>
---
include/linux/damon.h | 4 +++-
mm/damon/core.c | 14 ++++++++++----
mm/damon/lru_sort.c | 16 +++++++++++++---
mm/damon/modules-common.c | 5 ++++-
mm/damon/modules-common.h | 2 +-
mm/damon/reclaim.c | 16 +++++++++++++---
mm/damon/stat.c | 2 +-
7 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/include/linux/damon.h b/include/linux/damon.h
index b85c6c669cd0..1b7b4cf1a3c5 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -942,7 +942,9 @@ int damon_call(struct damon_ctx *ctx, struct damon_call_control *control);
int damos_walk(struct damon_ctx *ctx, struct damos_walk_control *control);
int damon_set_region_biggest_system_ram_default(struct damon_target *t,
- unsigned long *start, unsigned long *end);
+ unsigned long *start,
+ unsigned long *end,
+ unsigned long addr_unit);
#endif /* CONFIG_DAMON */
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 1a8d3009d606..803c30f64b94 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2714,6 +2714,7 @@ static bool damon_find_biggest_system_ram(unsigned long *start,
* @t: The monitoring target to set the region.
* @start: The pointer to the start address of the region.
* @end: The pointer to the end address of the region.
+ * @addr_unit: Scale factor for core to ops address conversion.
*
* This function sets the region of @t as requested by @start and @end. If the
* values of @start and @end are zero, however, this function finds the biggest
@@ -2724,16 +2725,21 @@ static bool damon_find_biggest_system_ram(unsigned long *start,
* Return: 0 on success, negative error code otherwise.
*/
int damon_set_region_biggest_system_ram_default(struct damon_target *t,
- unsigned long *start, unsigned long *end)
+ unsigned long *start,
+ unsigned long *end,
+ unsigned long addr_unit)
{
struct damon_addr_range addr_range;
if (*start > *end)
return -EINVAL;
- if (!*start && !*end &&
- !damon_find_biggest_system_ram(start, end))
- return -EINVAL;
+ if (!*start && !*end) {
+ if (!damon_find_biggest_system_ram(start, end) || !addr_unit)
+ return -EINVAL;
+ *start /= addr_unit;
+ *end /= addr_unit;
+ }
addr_range.start = *start;
addr_range.end = *end;
diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
index 151a9de5ad8b..8107d08c5e4b 100644
--- a/mm/damon/lru_sort.c
+++ b/mm/damon/lru_sort.c
@@ -111,6 +111,14 @@ module_param(monitor_region_start, ulong, 0600);
static unsigned long monitor_region_end __read_mostly;
module_param(monitor_region_end, ulong, 0600);
+/*
+ * Scale factor for DAMON_LRU_SORT to ops address conversion.
+ *
+ * This parameter is used to convert to the actual physical address.
+ */
+static unsigned long addr_unit __read_mostly = 1;
+module_param(addr_unit, ulong, 0600);
+
/*
* PID of the DAMON thread
*
@@ -194,7 +202,8 @@ static int damon_lru_sort_apply_parameters(void)
unsigned int hot_thres, cold_thres;
int err;
- err = damon_modules_new_paddr_ctx_target(¶m_ctx, ¶m_target);
+ err = damon_modules_new_paddr_ctx_target(¶m_ctx, ¶m_target,
+ addr_unit);
if (err)
return err;
@@ -221,7 +230,8 @@ static int damon_lru_sort_apply_parameters(void)
err = damon_set_region_biggest_system_ram_default(param_target,
&monitor_region_start,
- &monitor_region_end);
+ &monitor_region_end,
+ addr_unit);
if (err)
goto out;
err = damon_commit_ctx(ctx, param_ctx);
@@ -323,7 +333,7 @@ MODULE_PARM_DESC(enabled,
static int __init damon_lru_sort_init(void)
{
- int err = damon_modules_new_paddr_ctx_target(&ctx, &target);
+ int err = damon_modules_new_paddr_ctx_target(&ctx, &target, 1);
if (err)
goto out;
diff --git a/mm/damon/modules-common.c b/mm/damon/modules-common.c
index 86d58f8c4f63..613b7cc99368 100644
--- a/mm/damon/modules-common.c
+++ b/mm/damon/modules-common.c
@@ -13,9 +13,10 @@
* Allocate, set, and return a DAMON context for the physical address space.
* @ctxp: Pointer to save the point to the newly created context
* @targetp: Pointer to save the point to the newly created target
+ * @addr_unit: Scale factor for modules to ops address conversion.
*/
int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
- struct damon_target **targetp)
+ struct damon_target **targetp, unsigned long addr_unit)
{
struct damon_ctx *ctx;
struct damon_target *target;
@@ -24,6 +25,8 @@ int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
if (!ctx)
return -ENOMEM;
+ ctx->addr_unit = addr_unit;
+
if (damon_select_ops(ctx, DAMON_OPS_PADDR)) {
damon_destroy_ctx(ctx);
return -EINVAL;
diff --git a/mm/damon/modules-common.h b/mm/damon/modules-common.h
index f103ad556368..c7048a449321 100644
--- a/mm/damon/modules-common.h
+++ b/mm/damon/modules-common.h
@@ -46,4 +46,4 @@
0400);
int damon_modules_new_paddr_ctx_target(struct damon_ctx **ctxp,
- struct damon_target **targetp);
+ struct damon_target **targetp, unsigned long addr_unit);
diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index 3c71b4596676..0e11b121d693 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -128,6 +128,14 @@ module_param(monitor_region_start, ulong, 0600);
static unsigned long monitor_region_end __read_mostly;
module_param(monitor_region_end, ulong, 0600);
+/*
+ * Scale factor for DAMON_RECLAIM to ops address conversion.
+ *
+ * This parameter is used to convert to the actual physical address.
+ */
+static unsigned long addr_unit __read_mostly = 1;
+module_param(addr_unit, ulong, 0600);
+
/*
* Skip anonymous pages reclamation.
*
@@ -190,7 +198,8 @@ static int damon_reclaim_apply_parameters(void)
struct damos_filter *filter;
int err;
- err = damon_modules_new_paddr_ctx_target(¶m_ctx, ¶m_target);
+ err = damon_modules_new_paddr_ctx_target(¶m_ctx, ¶m_target,
+ addr_unit);
if (err)
return err;
@@ -229,7 +238,8 @@ static int damon_reclaim_apply_parameters(void)
err = damon_set_region_biggest_system_ram_default(param_target,
&monitor_region_start,
- &monitor_region_end);
+ &monitor_region_end,
+ addr_unit);
if (err)
goto out;
err = damon_commit_ctx(ctx, param_ctx);
@@ -327,7 +337,7 @@ MODULE_PARM_DESC(enabled,
static int __init damon_reclaim_init(void)
{
- int err = damon_modules_new_paddr_ctx_target(&ctx, &target);
+ int err = damon_modules_new_paddr_ctx_target(&ctx, &target, 1);
if (err)
goto out;
diff --git a/mm/damon/stat.c b/mm/damon/stat.c
index 87bcd8866d4b..ae7377e7409f 100644
--- a/mm/damon/stat.c
+++ b/mm/damon/stat.c
@@ -181,7 +181,7 @@ static struct damon_ctx *damon_stat_build_ctx(void)
if (!target)
goto free_out;
damon_add_target(ctx, target);
- if (damon_set_region_biggest_system_ram_default(target, &start, &end))
+ if (damon_set_region_biggest_system_ram_default(target, &start, &end, ctx->addr_unit))
goto free_out;
return ctx;
free_out:
--
2.34.1On Wed, 13 Aug 2025 13:07:01 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote: > In module DAMON_RECLAIM and DAMON_LRU_SORT, the damon_ctx is > independent of the core, necessitating dedicated addr_unit > integration for these features. > Additionally, if the input monitor_region_start and monitor_region_end > are both 0 while addr_unit is set to a non-zero valuethe default > system RAM range should be divided by addr_unit. Do you plan to, and need to use DAMON_RECLAIM and DAMON_LRU_SORT on LPAE-ARM32 environments? Can't you use DAMON sysfs interface instead? If need to use the modules, this change looks good to me in high level. But if not, I'd like to skip this change, and wait until someone requests it. I'll review the code change in depth after the above question is answered. Thanks, SJ [...]
在 2025/8/14 0:36, SeongJae Park 写道: > On Wed, 13 Aug 2025 13:07:01 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote: > >> In module DAMON_RECLAIM and DAMON_LRU_SORT, the damon_ctx is >> independent of the core, necessitating dedicated addr_unit >> integration for these features. >> Additionally, if the input monitor_region_start and monitor_region_end >> are both 0 while addr_unit is set to a non-zero valuethe default >> system RAM range should be divided by addr_unit. > Do you plan to, and need to use DAMON_RECLAIM and DAMON_LRU_SORT on LPAE-ARM32 > environments? Can't you use DAMON sysfs interface instead? If need to use the > modules, this change looks good to me in high level. But if not, I'd like to > skip this change, and wait until someone requests it. > > I'll review the code change in depth after the above question is answered. > Hi SJ, Yes, we need to use these modules in an LPAE-ARM32 environment. The modular approach often provides more flexibility in our workflow, so we would greatly appreciate it if you could take some time to review the code!🙂 Thanks, Quanmin Yan > > Thanks, > SJ > > [...] >
On Thu, 14 Aug 2025 20:59:04 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote: > > 在 2025/8/14 0:36, SeongJae Park 写道: > > On Wed, 13 Aug 2025 13:07:01 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote: > > > >> In module DAMON_RECLAIM and DAMON_LRU_SORT, the damon_ctx is > >> independent of the core, necessitating dedicated addr_unit > >> integration for these features. > >> Additionally, if the input monitor_region_start and monitor_region_end > >> are both 0 while addr_unit is set to a non-zero valuethe default > >> system RAM range should be divided by addr_unit. > > Do you plan to, and need to use DAMON_RECLAIM and DAMON_LRU_SORT on LPAE-ARM32 > > environments? Can't you use DAMON sysfs interface instead? If need to use the > > modules, this change looks good to me in high level. But if not, I'd like to > > skip this change, and wait until someone requests it. > > > > I'll review the code change in depth after the above question is answered. > > > Hi SJ, > > Yes, we need to use these modules in an LPAE-ARM32 environment. The modular > approach often provides more flexibility in our workflow, so we would greatly > appreciate it if you could take some time to review the code!🙂 Thank you for clarifying. Ok, I understand this change is really required. However, I think reviewing and revising this part may take time. Meanwhile, seems this part is not an essential one of this patch series, and has no problem at be separated and merged after the essential parts. So, could we separate this part from this patch series? That is, let's work on the essential part first. After the work on the essential part is done, you could post this part as another patch series, and then we can work together again on it. Thanks, SJ [...]
Hi SJ, 在 2025/8/15 0:11, SeongJae Park 写道: > On Thu, 14 Aug 2025 20:59:04 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote: > >> 在 2025/8/14 0:36, SeongJae Park 写道: >>> On Wed, 13 Aug 2025 13:07:01 +0800 Quanmin Yan <yanquanmin1@huawei.com> wrote: >>> >>>> In module DAMON_RECLAIM and DAMON_LRU_SORT, the damon_ctx is >>>> independent of the core, necessitating dedicated addr_unit >>>> integration for these features. >>>> Additionally, if the input monitor_region_start and monitor_region_end >>>> are both 0 while addr_unit is set to a non-zero valuethe default >>>> system RAM range should be divided by addr_unit. >>> Do you plan to, and need to use DAMON_RECLAIM and DAMON_LRU_SORT on LPAE-ARM32 >>> environments? Can't you use DAMON sysfs interface instead? If need to use the >>> modules, this change looks good to me in high level. But if not, I'd like to >>> skip this change, and wait until someone requests it. >>> >>> I'll review the code change in depth after the above question is answered. >>> >> Hi SJ, >> >> Yes, we need to use these modules in an LPAE-ARM32 environment. The modular >> approach often provides more flexibility in our workflow, so we would greatly >> appreciate it if you could take some time to review the code!🙂 > Thank you for clarifying. Ok, I understand this change is really required. > > However, I think reviewing and revising this part may take time. Meanwhile, > seems this part is not an essential one of this patch series, and has no > problem at be separated and merged after the essential parts. > > So, could we separate this part from this patch series? That is, let's work on > the essential part first. After the work on the essential part is done, you > could post this part as another patch series, and then we can work together > again on it. You are right, let's focus on the essential part first. Thanks, Quanmin Yan > > Thanks, > SJ > > [...]
© 2016 - 2025 Red Hat, Inc.