Re: [PATCH v5 14/36] mm/damon: skip private node memory in DAMON migration and pageout

[Gregory Price <gourry@gourry.net>]

On Wed, Jul 22, 2026 at 05:19:42PM -0700, SJ Park wrote:
> On Wed, 22 Jul 2026 08:16:56 -0400 Gregory Price <gourry@gourry.net> wrote:
> 
> > > "by default".  Does that mean it could be reclaimable in some situations?  If
> > > so, could we check if it is reclaimable?
> > > 
> > 
> > See the damon changes in:
> > 
> > https://lore.kernel.org/linux-mm/al-pkvmgIxGu3LzM@gourry-fedora-PF4VCD3F/T/#mfb99303c85dd9d4c3f58832dc28fc55583a7217a
> 
> Summarizing what you want to say, quoting something from the patch, or at least
> calling it "26th patch of this series" would have made reviewing much easier.
> Cc-ing damon@ for only patches that toucing DAMON source files and the cover
> letter of the series could also be helpful.  Please consider doing some of
> these for future replies.
> 

I have been very much discouraged from this kind of trimming because it
removes the context of the series from the individual patches - making it
even more confusing.

But I understand, I will try to remember to do this for you.

> So, I understand later patches will make it optionally reclaimable and update
> this restriction by the 26th patch?  That sounds fair.  But, could we drop "by
> default" from the above comment for reducing the confusion?

Yes, but you bring up a good point - I think this two-step process is
actually poor form and that I need to redo it.

Maybe this can be redone as node states (features?) such as:

   N_MEMORY_RECLAIMABLE
   N_MEMORY_DEMOTABLE
   N_MEMORY_TIERABLE

so these damon changes will forego this confusing intermediate step of:

   if (folio_is_private_node(folio))

and go straight to

   if (node_is_reclaimable(folio_nid(folio)))

In the first patch - without ever having to revisit damon again.

> > 
> > Technically there is nothing in migration core to prevent migration
> > operations, it's done on a service basis - hotunplug, reclaim/demotion,
> > user numa (mbind, migrate/move_pages) etc.
> > 
> > Operations on private nodes/private node folioes are refused if the
> > capability bit is not set.
> 
> I haven't had a chance to read the entire series, sorry about that.  So, do you
> mean the above blocking is not really needed, or that will conditionally be
> allowed by another later patch?
> 

I will reduce this all to a single patch in v6, I see where things can
be improved now based on a few pieces of feedback.

Thanks SJ!
~Gregory