[PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[Akinobu Mita]

This change avoids unnecessary migration by checking if the folio to which
the migration is applied is already located in one of the target nodes.

Cc: SeongJae Park <sj@kernel.org>
Cc: Bijan Tabatabai <bijantabatab@micron.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
---
 mm/damon/vaddr.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
index 87e825349bdf..d531763a3b2b 100644
--- a/mm/damon/vaddr.c
+++ b/mm/damon/vaddr.c
@@ -665,6 +665,7 @@ static bool damos_va_filter_out(struct damos *scheme, struct folio *folio,
 struct damos_va_migrate_private {
 	struct list_head *migration_lists;
 	struct damos *scheme;
+	nodemask_t dest_nodes;
 };
 
 /*
@@ -747,6 +748,8 @@ static int damos_va_migrate_pmd_entry(pmd_t *pmd, unsigned long addr,
 	if (!folio)
 		goto unlock;
 
+	if (node_isset(folio_nid(folio), priv->dest_nodes))
+		goto put_folio;
 	if (damos_va_filter_out(s, folio, walk->vma, addr, NULL, pmd))
 		goto put_folio;
 
@@ -781,6 +784,8 @@ static int damos_va_migrate_pte_entry(pte_t *pte, unsigned long addr,
 	if (!folio)
 		return 0;
 
+	if (node_isset(folio_nid(folio), priv->dest_nodes))
+		goto put_folio;
 	if (damos_va_filter_out(s, folio, walk->vma, addr, pte, NULL))
 		goto put_folio;
 
@@ -865,10 +870,13 @@ static unsigned long damos_va_migrate(struct damon_target *target,
 		sizeof(*priv.migration_lists), GFP_KERNEL);
 	if (!priv.migration_lists)
 		return 0;
+	priv.dest_nodes = NODE_MASK_NONE;
 
-	for (int i = 0; i < nr_dests; i++)
+	for (int i = 0; i < nr_dests; i++) {
 		INIT_LIST_HEAD(&priv.migration_lists[i]);
-
+		node_set(use_target_nid ? s->target_nid : dests->node_id_arr[i],
+				priv.dest_nodes);
+	}
 
 	mm = damon_get_mm(target);
 	if (!mm)
-- 
2.34.1

Re: [PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[SeongJae Park]

Hello Akinobu,

On Sun,  3 Aug 2025 22:00:28 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:

> This change avoids unnecessary migration by checking if the folio to which
> the migration is applied is already located in one of the target nodes.

Each folio will get a single target node among the target nodes, based on the
weights of targets and the virtual address of the folio.  So skipping the
migration because the folio is on one of target nodes can result in wrong
behavior (not doing required migrations)?

Also, a similar purpose optimization was already made by Bijan.  I guess you
aware of that and therefore Cc-ed Bijan.  Could you further share differences
between this and Bijan's one, and measured additional performance gain from
this patch, if you have?

[1] https://lkml.kernel.org/r/20250725163300.4602-1-bijan311@gmail.com


Thanks,
SJ

[...]

Re: [PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[Akinobu Mita]

Hi,

2025年8月4日(月) 3:01 SeongJae Park <sj@kernel.org>:
>
> Hello Akinobu,
>
> On Sun,  3 Aug 2025 22:00:28 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
>
> > This change avoids unnecessary migration by checking if the folio to which
> > the migration is applied is already located in one of the target nodes.
>
> Each folio will get a single target node among the target nodes, based on the
> weights of targets and the virtual address of the folio.  So skipping the
> migration because the folio is on one of target nodes can result in wrong
> behavior (not doing required migrations)?
>
> Also, a similar purpose optimization was already made by Bijan.  I guess you
> aware of that and therefore Cc-ed Bijan.  Could you further share differences
> between this and Bijan's one, and measured additional performance gain from
> this patch, if you have?
>
> [1] https://lkml.kernel.org/r/20250725163300.4602-1-bijan311@gmail.com

In my current DAMON setup, the target nodes for migrate_hot action
are 0-3, and for migrate_cold action, they are 4 and 5.

I'm looking for a way to prevent unnecessary movement between target
nodes for each action, making interleaving an optional choice. For
instance, I'd like to avoid migrations from node 4 to node 5 during a
migrate_cold action.

I've observed a difference in behavior compared to Bijan's patch, and
it seems there's a need for both approaches. Would it be possible to
introduce a new option that allows us to specify whether interleaving
is forced or optional, and then adjust the behavior based on that
setting?

Re: [PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[Bijan Tabatabai]

On Mon, 4 Aug 2025 21:46:49 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:

> Hi,
> 
> 2025年8月4日(月) 3:01 SeongJae Park <sj@kernel.org>:
> >
> > Hello Akinobu,
> >
> > On Sun,  3 Aug 2025 22:00:28 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> >
> > > This change avoids unnecessary migration by checking if the folio to which
> > > the migration is applied is already located in one of the target nodes.
> >
> > Each folio will get a single target node among the target nodes, based on the
> > weights of targets and the virtual address of the folio.  So skipping the
> > migration because the folio is on one of target nodes can result in wrong
> > behavior (not doing required migrations)?
> >
> > Also, a similar purpose optimization was already made by Bijan.  I guess you
> > aware of that and therefore Cc-ed Bijan.  Could you further share differences
> > between this and Bijan's one, and measured additional performance gain from
> > this patch, if you have?
> >
> > [1] https://lkml.kernel.org/r/20250725163300.4602-1-bijan311@gmail.com
> 
> In my current DAMON setup, the target nodes for migrate_hot action
> are 0-3, and for migrate_cold action, they are 4 and 5.
> 
> I'm looking for a way to prevent unnecessary movement between target
> nodes for each action, making interleaving an optional choice. For
> instance, I'd like to avoid migrations from node 4 to node 5 during a
> migrate_cold action.

Where a folio is placed is based on the virtual address of the folio and
the folio's offset from the start of the VMA it is in. So, as long as the
interleave weights and the folio's offset in the VMA are the same, folios
should not be migrated after being placed. This placement algorithm is the
same as the one used for mempolicy weighted interleaving.

It sounds like you are keeping the interleave weights constant, and I would
imagine that the virtual addresses the folios are mapped to are constant,
so I'm guessing the start address of some VMAs are changing. I don't think
I've seen the bahvior your describing in the workloads I've run, but I
guess it's possible if VMAs are being merged or broken up a lot, such as
through frequent mmaps/munmaps. Do you think something like this is
happening in your workload?

How often are the undesired migrations happening? Every time the scheme is
applied?
Also, would you be willing to share how you are configuring DAMON?

> I've observed a difference in behavior compared to Bijan's patch, and
> it seems there's a need for both approaches. Would it be possible to
> introduce a new option that allows us to specify whether interleaving
> is forced or optional, and then adjust the behavior based on that
> setting?

I wonder if this would be better handled as a paddr scheme. That way
you can configure the schemes such that only physical addresses in nodes
4-5 will migrate pages to nodes 0-3, and only physical address in nodes 0-3
will migrate to nodes 4-5.

Bijan

Re: [PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[SeongJae Park]

On Mon,  4 Aug 2025 10:19:20 -0500 Bijan Tabatabai <bijan311@gmail.com> wrote:

> On Mon, 4 Aug 2025 21:46:49 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> 
> > Hi,
> > 
> > 2025年8月4日(月) 3:01 SeongJae Park <sj@kernel.org>:
> > >
> > > Hello Akinobu,
> > >
> > > On Sun,  3 Aug 2025 22:00:28 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> > >
> > > > This change avoids unnecessary migration by checking if the folio to which
> > > > the migration is applied is already located in one of the target nodes.
> > >
> > > Each folio will get a single target node among the target nodes, based on the
> > > weights of targets and the virtual address of the folio.  So skipping the
> > > migration because the folio is on one of target nodes can result in wrong
> > > behavior (not doing required migrations)?
> > >
> > > Also, a similar purpose optimization was already made by Bijan.  I guess you
> > > aware of that and therefore Cc-ed Bijan.  Could you further share differences
> > > between this and Bijan's one, and measured additional performance gain from
> > > this patch, if you have?
> > >
> > > [1] https://lkml.kernel.org/r/20250725163300.4602-1-bijan311@gmail.com
> > 
> > In my current DAMON setup, the target nodes for migrate_hot action
> > are 0-3, and for migrate_cold action, they are 4 and 5.
> > 
> > I'm looking for a way to prevent unnecessary movement between target
> > nodes for each action, making interleaving an optional choice. For
> > instance, I'd like to avoid migrations from node 4 to node 5 during a
> > migrate_cold action.
> 
> Where a folio is placed is based on the virtual address of the folio and
> the folio's offset from the start of the VMA it is in. So, as long as the
> interleave weights and the folio's offset in the VMA are the same, folios
> should not be migrated after being placed. This placement algorithm is the
> same as the one used for mempolicy weighted interleaving.
> 
> It sounds like you are keeping the interleave weights constant, and I would
> imagine that the virtual addresses the folios are mapped to are constant,
> so I'm guessing the start address of some VMAs are changing. I don't think
> I've seen the bahvior your describing in the workloads I've run, but I
> guess it's possible if VMAs are being merged or broken up a lot, such as
> through frequent mmaps/munmaps. Do you think something like this is
> happening in your workload?
> 
> How often are the undesired migrations happening? Every time the scheme is
> applied?
> Also, would you be willing to share how you are configuring DAMON?

I also want to learn more about your setup, use cases, and measured amount of
problem and benefit if you have.

> 
> > I've observed a difference in behavior compared to Bijan's patch, and
> > it seems there's a need for both approaches. Would it be possible to
> > introduce a new option that allows us to specify whether interleaving
> > is forced or optional, and then adjust the behavior based on that
> > setting?

We can add options if it is promising.  I have no good idea about if this is
promising or not for now.  It would be helpful if you could share more details
about your use cases and measurements.

> 
> I wonder if this would be better handled as a paddr scheme. That way
> you can configure the schemes such that only physical addresses in nodes
> 4-5 will migrate pages to nodes 0-3, and only physical address in nodes 0-3
> will migrate to nodes 4-5.

Agreed.  If Akinobu's use case is not depend on virtual address space, I think
paddr is a feasible direction to go.  Note that 'paddr' doesn't support
multiple destination nodes for now, so development of that would be needed if
we decide to go in this way.  But, again, I'd love to learn more about
Akinobu's use case and the problem first.


Thanks,
SJ

[...]

Re: [PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[Akinobu Mita]

2025年8月5日(火) 1:43 SeongJae Park <sj@kernel.org>:
>
> On Mon,  4 Aug 2025 10:19:20 -0500 Bijan Tabatabai <bijan311@gmail.com> wrote:
>
> > On Mon, 4 Aug 2025 21:46:49 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > 2025年8月4日(月) 3:01 SeongJae Park <sj@kernel.org>:
> > > >
> > > > Hello Akinobu,
> > > >
> > > > On Sun,  3 Aug 2025 22:00:28 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> > > >
> > > > > This change avoids unnecessary migration by checking if the folio to which
> > > > > the migration is applied is already located in one of the target nodes.
> > > >
> > > > Each folio will get a single target node among the target nodes, based on the
> > > > weights of targets and the virtual address of the folio.  So skipping the
> > > > migration because the folio is on one of target nodes can result in wrong
> > > > behavior (not doing required migrations)?
> > > >
> > > > Also, a similar purpose optimization was already made by Bijan.  I guess you
> > > > aware of that and therefore Cc-ed Bijan.  Could you further share differences
> > > > between this and Bijan's one, and measured additional performance gain from
> > > > this patch, if you have?
> > > >
> > > > [1] https://lkml.kernel.org/r/20250725163300.4602-1-bijan311@gmail.com
> > >
> > > In my current DAMON setup, the target nodes for migrate_hot action
> > > are 0-3, and for migrate_cold action, they are 4 and 5.
> > >
> > > I'm looking for a way to prevent unnecessary movement between target
> > > nodes for each action, making interleaving an optional choice. For
> > > instance, I'd like to avoid migrations from node 4 to node 5 during a
> > > migrate_cold action.
> >
> > Where a folio is placed is based on the virtual address of the folio and
> > the folio's offset from the start of the VMA it is in. So, as long as the
> > interleave weights and the folio's offset in the VMA are the same, folios
> > should not be migrated after being placed. This placement algorithm is the
> > same as the one used for mempolicy weighted interleaving.
> >
> > It sounds like you are keeping the interleave weights constant, and I would
> > imagine that the virtual addresses the folios are mapped to are constant,
> > so I'm guessing the start address of some VMAs are changing. I don't think
> > I've seen the bahvior your describing in the workloads I've run, but I
> > guess it's possible if VMAs are being merged or broken up a lot, such as
> > through frequent mmaps/munmaps. Do you think something like this is
> > happening in your workload?
> >
> > How often are the undesired migrations happening? Every time the scheme is
> > applied?
> > Also, would you be willing to share how you are configuring DAMON?
>
> I also want to learn more about your setup, use cases, and measured amount of
> problem and benefit if you have.
>
> >
> > > I've observed a difference in behavior compared to Bijan's patch, and
> > > it seems there's a need for both approaches. Would it be possible to
> > > introduce a new option that allows us to specify whether interleaving
> > > is forced or optional, and then adjust the behavior based on that
> > > setting?
>
> We can add options if it is promising.  I have no good idea about if this is
> promising or not for now.  It would be helpful if you could share more details
> about your use cases and measurements.
>
> >
> > I wonder if this would be better handled as a paddr scheme. That way
> > you can configure the schemes such that only physical addresses in nodes
> > 4-5 will migrate pages to nodes 0-3, and only physical address in nodes 0-3
> > will migrate to nodes 4-5.
>
> Agreed.  If Akinobu's use case is not depend on virtual address space, I think
> paddr is a feasible direction to go.  Note that 'paddr' doesn't support
> multiple destination nodes for now, so development of that would be needed if
> we decide to go in this way.  But, again, I'd love to learn more about
> Akinobu's use case and the problem first.

In my use case, a script periodically checks the processes in a cgroup and adds
new processes to the monitor targets, so the target processes change over time.
(Processes known to be short-lived or have low memory usage are excluded)

As you point out, even without the patch I suggested, it seems unlikely that
continuous migration between target nodes would occur.  The reason I proposed
this patch is that I didn't want to move any pages that were already located in
one of the target nodes.

It's true that paddr is more suitable, so I'd like to evaluate it using paddr
and compare which one is better.  However, these processes have different
performance requirements, so vaddr may be a better choice as it may be possible
to extend special handling depending on the target process.

Re: [PATCH] mm/damon/vaddr: avoid unnecessary migration between target nodes

[SeongJae Park]

On Wed, 6 Aug 2025 01:04:47 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:

> 2025年8月5日(火) 1:43 SeongJae Park <sj@kernel.org>:
> >
> > On Mon,  4 Aug 2025 10:19:20 -0500 Bijan Tabatabai <bijan311@gmail.com> wrote:
> >
> > > On Mon, 4 Aug 2025 21:46:49 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > 2025年8月4日(月) 3:01 SeongJae Park <sj@kernel.org>:
> > > > >
> > > > > Hello Akinobu,
> > > > >
> > > > > On Sun,  3 Aug 2025 22:00:28 +0900 Akinobu Mita <akinobu.mita@gmail.com> wrote:
> > > > >
> > > > > > This change avoids unnecessary migration by checking if the folio to which
> > > > > > the migration is applied is already located in one of the target nodes.
[...]
> > Agreed.  If Akinobu's use case is not depend on virtual address space, I think
> > paddr is a feasible direction to go.  Note that 'paddr' doesn't support
> > multiple destination nodes for now, so development of that would be needed if
> > we decide to go in this way.  But, again, I'd love to learn more about
> > Akinobu's use case and the problem first.
> 
> In my use case, a script periodically checks the processes in a cgroup and adds
> new processes to the monitor targets, so the target processes change over time.
> (Processes known to be short-lived or have low memory usage are excluded)

Thank you for sharing this!

I'm curious in more details, though.  Could you share what you want to achieve
with it, what DAMON parameters you are using for that, and how well or bad the
results match with your expectation?

> 
> As you point out, even without the patch I suggested, it seems unlikely that
> continuous migration between target nodes would occur.  The reason I proposed
> this patch is that I didn't want to move any pages that were already located in
> one of the target nodes.
> 
> It's true that paddr is more suitable, so I'd like to evaluate it using paddr
> and compare which one is better.

Soudns good, I'm looking forward to the evaluation results!  Let me know if any
help is needed.

> However, these processes have different
> performance requirements, so vaddr may be a better choice as it may be possible
> to extend special handling depending on the target process.

We have implemented memcg type DAMOS filter[1] for such a case.  You can use
the filter to make a given DAMOS scheme's action be applied to only pages that
owned by specific cgroups or not.

We also recently posted an RFC patch series[2] for memcg-aware auto-tuned
memory tiering.  The RFC patch series is not yet upstreamed since I found no
time to further test it.  It would be helpful if you could test and share the
results.

Again, I'm looking forward to more details of your use case and evaluation
results.  Let me know if there is anything I can help.

[1] https://docs.kernel.org/mm/damon/design.html#filters
[2] https://lore.kernel.org/20250619220023.24023-1-sj@kernel.org


Thanks,
SJ