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