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

[Balbir Singh]

On 1/13/26 08:10, dan.j.williams@xxxxxxxxx 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)

Balbir