On Wed, Jul 22, 2026 at 05:19:42PM -0700, SJ Park wrote: > On Wed, 22 Jul 2026 08:16:56 -0400 Gregory Price <[email protected]> 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
