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

[<dan.j.williams@intel.com>]

Gregory Price wrote:
> On Tue, Jan 13, 2026 at 09:54:32AM +1100, Balbir Singh wrote:
> > On 1/13/26 08:10, dan.j.williams@intel.com wrote:
> > > Balbir Singh wrote:
> > > [..]
> > >>> I agree with Gregory the name does not matter as much as the
> > >>> documentation explaining what the name means. I am ok if others do not
> > >>> sign onto the rationale for why not include _MEMORY, but lets capture
> > >>> something that tries to clarify that this is a unique node state that
> > >>> can have "all of the above" memory types relative to the existing
> > >>> _MEMORY states.
> > >>>
> > >>
> > >> To me, N_ is a common prefix, we do have N_HIGH_MEMORY, N_NORMAL_MEMORY.
> > >> N_PRIVATE does not tell me if it's CPU or memory related.
> > > 
> > > True that confusion about whether N_PRIVATE can apply to CPUs is there.
> > > How about split the difference and call this:
> > > 
> > >     N_MEM_PRIVATE
> > > 
> > > To make it both distinct from _MEMORY and _HIGH_MEMORY which describe
> > > ZONE limitations and distinct from N_CPU.
> > 
> > I'd be open to that name, how about N_MEMORY_PRIVATE? So then N_MEMORY
> > becomes (N_MEMORY_PUBLIC by default)
> >
> 
> N_MEMORY_PUBLIC is forcing everyone else to change for the sake a new
> feature, better to keep it N_MEM[ORY]_PRIVATE if anything

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