[PATCH] mm/damon: prevent migration fallback to non-target nodes

[PATCH] mm/damon: prevent migration fallback to non-target nodes

[zjh]

DAMOS_MIGRATE_{HOT,COLD} passes a target NUMA node to migrate_pages().
But alloc_migration_target() treats mtc->nid as a preferred node unless
__GFP_THISNODE is set.  Hence target allocation can fall back to another
node, and migrate_pages() can report success without placing the folio on
the requested target node.

Make DAMON migration target allocation strict by setting __GFP_THISNODE.
This is consistent with alloc_misplaced_dst_folio() and
alloc_demote_folio(), which also use __GFP_THISNODE for migrations to an
explicit destination node.

Signed-off-by: zjh <jiahuitry@outlook.com>
---
 mm/damon/ops-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
index 6bdd1cfd3863..d21b106b81ca 100644
--- a/mm/damon/ops-common.c
+++ b/mm/damon/ops-common.c
@@ -311,7 +311,7 @@ static unsigned int __damon_migrate_folio_list(
 		 * instead of migrated.
 		 */
 		.gfp_mask = (GFP_HIGHUSER_MOVABLE & ~__GFP_RECLAIM) |
-			__GFP_NOMEMALLOC | GFP_NOWAIT,
+			__GFP_NOMEMALLOC | GFP_NOWAIT | __GFP_THISNODE,
 		.nid = target_nid,
 	};
 

base-commit: 42db70db0bf4f1aa4eac4ddbe121143131b793df
-- 
2.53.0

Re: [PATCH] mm/damon: prevent migration fallback to non-target nodes

[SJ Park]

Hello jzh,

On Wed,  8 Jul 2026 01:07:54 -0700 zjh <jiahuitry@outlook.com> wrote:

> DAMOS_MIGRATE_{HOT,COLD} passes a target NUMA node to migrate_pages().
> But alloc_migration_target() treats mtc->nid as a preferred node unless
> __GFP_THISNODE is set.  Hence target allocation can fall back to another
> node, and migrate_pages() can report success without placing the folio on
> the requested target node.
> 
> Make DAMON migration target allocation strict by setting __GFP_THISNODE.
> This is consistent with alloc_misplaced_dst_folio() and
> alloc_demote_folio(), which also use __GFP_THISNODE for migrations to an
> explicit destination node.

Thank you for sharing this patch.  So this patch is introducing a small
behavioral change.  May I ask why you think the new behavior is better?  Have
you find some negative user impacts from the current behavior?

> 
> Signed-off-by: zjh <jiahuitry@outlook.com>

We as the kernel community disallow [1] anonymous patch submissions.  Is zjh
your preferred identity?  Also, it is not a strict rule, but we as the mm
community prefer using a formal name if that's ok.

[1] https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1


Thanks,
SJ

[...]

Re: [PATCH] mm/damon: prevent migration fallback to non-target nodes

[Jiahui Zhang]

Hi SJ,

Thank you for the review.

On Wed, Jul 08, 2026 at 07:11:33AM -0700, SJ Park wrote:
> So this patch is introducing a small behavioral change.  May I ask
> why you think the new behavior is better?  Have you find some 
> negative user impacts from the current behavior?

Consider a two-node tiered system, where node 0 is the fast tier and 
node 1 is a CPU-less slow tier, such as CXL memory.  Suppose node 0 
is nearly full and the user wants to promote hot regions (which reside
on node 1) to node 0 with a command like:

  sudo damo start --ops vaddr --target_pid ${workload_pid} \
      --damos_action migrate_hot 0 \
      --damos_access_rate 70% max

Without the __GFP_THISNODE flag, when the memory allocator finds that
node 0 is nearly full, it can fall back to node 1 without waking up 
kswapd. Then the pages allocated for migrate_pages() are still on node 1, 
and the regions that are expected to be promoted to node 0 are only moved
 to different physical pages on node 1.

As a result, the NUMA node placement does not change, but the following
command still observes successful migrations:

  sudo bpftrace -e '
  tracepoint:migrate:mm_migrate_pages /args->reason == 9/
  {
      @succeeded_pages = sum(args->succeeded);
  }
  interval:s:1
  {
      time("%H:%M:%S ");
      print(@succeeded_pages);
      clear(@succeeded_pages);
  }'

I've also checked other page migration paths, such as alloc_demote_folio(),
 alloc_misplaced_dst_folio() and do_move_pages_to_node(), all of which set
the __GFP_THISNODE flag.

I am not sure whether the original design intended to provide only
best-effort semantics, but I found this behavior very confusing in my
experiment.

> We as the kernel community disallow [1] anonymous patch submissions.  Is zjh
> your preferred identity?  Also, it is not a strict rule, but we as the mm
> community prefer using a formal name if that's ok.

Sorry I did not notice this.  If you think the GFP flag should be added, I will
send a v2 of the patch and correct the Signed-off-by issue.

Thanks,
Jiahui Zhang

Re: [PATCH] mm/damon: prevent migration fallback to non-target nodes

[SJ Park]

+ Honggyu for origin intent of not adding __GFP_THISNODE

On Wed, 8 Jul 2026 10:55:05 -0700 Jiahui Zhang <jiahuitry@outlook.com> wrote:

> Hi SJ,
> 
> Thank you for the review.
> 
> On Wed, Jul 08, 2026 at 07:11:33AM -0700, SJ Park wrote:
> > So this patch is introducing a small behavioral change.  May I ask
> > why you think the new behavior is better?  Have you find some 
> > negative user impacts from the current behavior?
> 
> Consider a two-node tiered system, where node 0 is the fast tier and 
> node 1 is a CPU-less slow tier, such as CXL memory.  Suppose node 0 
> is nearly full and the user wants to promote hot regions (which reside
> on node 1) to node 0 with a command like:
> 
>   sudo damo start --ops vaddr --target_pid ${workload_pid} \
>       --damos_action migrate_hot 0 \
>       --damos_access_rate 70% max
> 
> Without the __GFP_THISNODE flag, when the memory allocator finds that
> node 0 is nearly full, it can fall back to node 1 without waking up 
> kswapd.

Have you considered or tested running demotion-purpose DAMOS scheme together?

> Then the pages allocated for migrate_pages() are still on node 1, 
> and the regions that are expected to be promoted to node 0 are only moved
>  to different physical pages on node 1.
> 
> As a result, the NUMA node placement does not change, but the following
> command still observes successful migrations:
> 
>   sudo bpftrace -e '
>   tracepoint:migrate:mm_migrate_pages /args->reason == 9/
>   {
>       @succeeded_pages = sum(args->succeeded);
>   }
>   interval:s:1
>   {
>       time("%H:%M:%S ");
>       print(@succeeded_pages);
>       clear(@succeeded_pages);
>   }'
> 
> I've also checked other page migration paths, such as alloc_demote_folio(),
>  alloc_misplaced_dst_folio() and do_move_pages_to_node(), all of which set
> the __GFP_THISNODE flag.
> 
> I am not sure whether the original design intended to provide only
> best-effort semantics,

To my understanding, it was initially trying to reflect what
demote_folio_list() does.  Because it doesn't have ___GFP_THISNODE, this
function also ended up not having it without a very serious reason.

My mental model of DAMOS_MIGRATE_{HOT,COLD} nowadays is like move_pages().
And I find do_move_pages_to_node(), which is used by move_pages() is also using
the flag.

So I think adding the flag is ok.  Cc-ed Honggyu for a case he has different
opinions, though.

> but I found this behavior very confusing in my
> experiment.

Thank you for sharing this pain point.

I agree this can be very confusing for inveestigations.  Not just confusing but
makes investigations of this case nearly impossible, iiuc.  DAMOS provides its
own stats for succeeded and failed operations, but that will again not be
helpful since migrate_pages would returned success in this case.

So, yes, let's add the flag unless someone else has a different opinions.

> 
> > We as the kernel community disallow [1] anonymous patch submissions.  Is zjh
> > your preferred identity?  Also, it is not a strict rule, but we as the mm
> > community prefer using a formal name if that's ok.
> 
> Sorry I did not notice this.  If you think the GFP flag should be added, I will
> send a v2 of the patch and correct the Signed-off-by issue.

Yes, please give others time to comment on (say, one day?) and proceed to v2 if
nobody disagrees to.

On the version, could you please add the clarification of the pain points you
encountered, and how this change made it disappeared?

Also, let's change the subject prefix from mm/damon: to mm/damon/ops-common:


Thanks,
SJ

[...]

Re: [PATCH] mm/damon: prevent migration fallback to non-target nodes

[Jiahui Zhang]

Hi SJ,

On Wed, Jul 08, 2026 at 05:37:51PM -0700, SJ Park wrote:
> > > So this patch is introducing a small behavioral change.  May I ask
> > > why you think the new behavior is better?  Have you find some 
> > > negative user impacts from the current behavior?
> > 
> > Consider a two-node tiered system, where node 0 is the fast tier and 
> > node 1 is a CPU-less slow tier, such as CXL memory.  Suppose node 0 
> > is nearly full and the user wants to promote hot regions (which reside
> > on node 1) to node 0 with a command like:
> > 
> >   sudo damo start --ops vaddr --target_pid ${workload_pid} \
> >       --damos_action migrate_hot 0 \
> >       --damos_access_rate 70% max
> > 
> > Without the __GFP_THISNODE flag, when the memory allocator finds that
> > node 0 is nearly full, it can fall back to node 1 without waking up 
> > kswapd.
> 
> Have you considered or tested running demotion-purpose DAMOS scheme together?

Yes. Running promotion and demotion schemes together allows hot regions to
be successfully promoted. However, if demotion does not catch up with the
promotion rate, allocation fallback can still happen during promotion. 
In that case, both the migrate_pages() accounting and the DAMOS statistics
(i.e., sz_applied) reported by the damos_stat_after_apply_interval 
tracepoint still show misleading numbers.

> > 
> > > We as the kernel community disallow [1] anonymous patch submissions.  Is zjh
> > > your preferred identity?  Also, it is not a strict rule, but we as the mm
> > > community prefer using a formal name if that's ok.
> > 
> > Sorry I did not notice this.  If you think the GFP flag should be added, I will
> > send a v2 of the patch and correct the Signed-off-by issue.
> 
> Yes, please give others time to comment on (say, one day?) and proceed to v2 if
> nobody disagrees to.
> 
> On the version, could you please add the clarification of the pain points you
> encountered, and how this change made it disappeared?
> 
> Also, let's change the subject prefix from mm/damon: to mm/damon/ops-common:
> 

Yes, I'll do so.

Thanks,
Jiahui Zhang