Re: [RFC PATCH v3 0/8] mm,numa: N_PRIVATE node isolation for device-managed memory

[dan.j.williams]

Gregory Price wrote:
> On Mon, Jan 12, 2026 at 05:17:53PM -0800, dan.j.williams@xxxxxxxxx wrote:
> > 
> > I think what Balbir is saying is that the _PUBLIC is implied and can be
> > omitted. It is true that N_MEMORY[_PUBLIC] already indicates multi-zone
> > support. So N_MEMORY_PRIVATE makes sense to me as something that it is
> > distinct from N_{HIGH,NORMAL}_MEMORY which are subsets of N_MEMORY.
> > Distinct to prompt "go read the documentation to figure out why this
> > thing looks not like the others".
> 
> Ah, ack.  Will update for v4 once i give some thought to the compression
> stuff and the cgroups notes.
> 
> I would love if the ZONE_DEVICE folks could also chime in on whether the
> callback structures for pgmap and hmm might be re-usable here, but might
> take a few more versions to get the attention of everyone.

page->pgmap clobbers page->lru, i.e. they share the same union, so you
could not directly use the current ZONE_DEVICE scheme. That is because
current ZONE_DEVICE scheme needs to support ZONE_DEVICE mixed with
ZONE_NORMAL + ZONE_MOVABLE in the same node.

However, with N_MEMORY_PRIVATE effectively enabling a "node per device"
construct, you could move 'struct dev_pagemap' to node scope. I.e.
rather than annotate each page with which device it belongs teach
pgmap->ops callers to consider that the dev_pagemap instance may come
from the node instead.