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

From: Gregory Price

Date: Wed Jul 22 2026 - 23:27:01 EST


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@xxxxxxxxxx> 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