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

[SJ Park <sj@kernel.org>]

On Wed, 22 Jul 2026 23:25:15 -0400 Gregory Price <gourry@gourry.net> wrote:

> 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.

That's fair and making sense.

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

Thank you, Gregory.  Nonetheless, I wouldn't insist selective Cc-ing.  I agree
your point, and I expect doing that would be tedious if you don't have a script
or tool (I use a tool).  It is just one of my suggestion to help reviewing in
this context, insted of only lore link.  Just one among the other three
suggestions (summarizing your thought, quoting, or simply calling it "26th
patch of this series") should also suffice.

> 
> > 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.

Indeed that sounds better than my suggestion.

> 
> > > 
> > > 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.

Sounds good, thank you Gregory.  Looking forward to the next version!


Thanks,
SJ

[...]