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

[Balbir Singh <balbirs@nvidia.com>]

On 1/13/26 07:24, dan.j.williams@intel.com wrote:
> Yury Norov wrote:
> [..]
>>> Dan Williams convinced me to go with N_PRIVATE, but this is really a
>>> bikeshed topic
>>
>> No it's not. To me (OK, an almost random reader in this discussion),
>> N_PRIVATE is a pretty confusing name. It doesn't answer the question:
>> private what? N_PRIVATE_MEMORY is better in that department, isn't?
>>
>> But taking into account isolcpus, maybe N_ISOLMEM?
>>
>>> - we could call it N_BOBERT until we find consensus.
>>
>> Please give it the right name well describing the scope and purpose of
>> the new restriction policy before moving forward.
> 
> ...this is the definition of a bikeshed discussion, and bikeshed's are
> important for building consensus. The argument for N_PRIVATE is with
> respect to looking at this from the perspective of the other node_states
> that do not have the _MEMORY designation particularly _ONLINE and the
> fact that the other _MEMORY states implied zone implications whereas
> N_PRIVATE can span zones.
> 
> 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.

Balbir