On Wed, 22 Jul 2026 08:16:56 -0400 Gregory Price <[email protected]> wrote:
> On Tue, Jul 21, 2026 at 04:46:43PM -0700, SJ Park wrote: > > On Mon, 20 Jul 2026 15:34:08 -0400 Gregory Price <[email protected]> wrote: > > > > > DAMON operates on physical address ranges, which can cover private > > > node memory. Skip private-node folios in both DAMON's migration > > > and reclaim paths. > > > > > > Signed-off-by: Gregory Price <[email protected]> > > > --- > > > mm/damon/paddr.c | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c > > > index e4f98d67461f5..c741a94319750 100644 > > > --- a/mm/damon/paddr.c > > > +++ b/mm/damon/paddr.c > > > @@ -12,6 +12,7 @@ > > > #include <linux/swap.h> > > > #include <linux/memory-tiers.h> > > > #include <linux/mm_inline.h> > > > +#include <linux/node_private.h> > > > > > > #include "../internal.h" > > > #include "ops-common.h" > > > @@ -250,6 +251,10 @@ static unsigned long damon_pa_pageout(struct > > > damon_region *r, > > > continue; > > > } > > > > > > + /* private node memory is not reclaimable by default */ > > > + if (folio_is_private_node(folio)) > > > + goto put_folio; > > > + > > > > "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. 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? > > > Also, what happens if we just try paging out the private node memory? Will > > it > > simply fail? Or, make some problems? > > > > user controls for MADV_ commands that affect private node folios would > skip those folios - exactly same as ZONE_DEVICE folios. > > Which I'm not sure damon actually handles correctly presently (zone > device). I remember looking around damon and thinking to myself "what > if this is a zone device page?" and not being able to find a satisfying > answer. > > > > if (damos_pa_filter_out(s, folio)) > > > goto put_folio; > > > else > > > @@ -344,6 +349,10 @@ static unsigned long damon_pa_migrate(struct > > > damon_region *r, > > > else > > > *sz_filter_passed += folio_size(folio) / addr_unit; > > > > > > + /* private nodes do not support migration by default */ > > > + if (folio_is_private_node(folio)) > > > + goto put_folio; > > > + > > > > Same questions. > > > > 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? Thanks, SJ [...]
