Re: [PATCH v5 00/36] Private Memory NUMA Nodes

Balbir Singh <[email protected]>
Newsgroups dev.linux.lists.damon,dev.linux.lists.driver-core,dev.linux.lists.nvdimm,org.kernel.vger.cgroups,org.kernel.vger.kvm,org.kernel.vger.linux-cxl,org.kernel.vger.linux-debuggers,org.kernel.vger.linux-doc,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kvack.linux-mm
Message-ID <[email protected]>
On 7/22/26 4:16 AM, Gregory Price wrote:
> On Tue, Jul 21, 2026 at 01:46:01PM +1000, Balbir Singh wrote:
>> On 7/21/26 5:33 AM, Gregory Price wrote:
>>>
>>> Patch Layout
>>> ============
>>> The series is broken into two sections:
>>>
>>> 1) N_MEMORY_PRIVATE Introduction.
>>>    Introduce the node state.
>>>    Opt those nodes out of mm/ services.
>>>
>>> 2) NODE_PRIVATE_CAP_* features
>>>    A set of mm/ service opt-in flags that augment private
>>>    nodes to make them more useful (i.e. reclaim = overcommit).
>>>
>>>    NODE_PRIVATE_CAP_LTPIN for private node folio pinning
>>>    NODE_PRIVATE_CAP_NUMA_BALANCING for private-node NUMA balancing
>>>    NODE_PRIVATE_CAP_DEMOTION for private-node tiering demotion
>>>    NODE_PRIVATE_CAP_HOTUNPLUG for opted-in private nodes
>>>    NODE_PRIVATE_CAP_USER_NUMA for userland numa controls
>>>    NODE_PRIVATE_CAP_RECLAIM for opted-in private node reclaim
>>>
>>
>> Looks reasonable, I wonder why USER_NUMA/HOTUNPUG is an opt-in?
>>
> 
> Ideologically: Private nodes default to fully isolated, why should any
> given feature be special?
> 
> Concretely: 
> 
> User-numa
> 
>    Some devices don't want the user to have control over placement.
>    I have been working on compressed memory, for example, which only
>    ever wants to be used as a reclaim-demotion target.
>    
>    (The reasoning for this is another thread, i plan on publishing
>     my research on this this year)
> 

I don't fully understand, how do we allocate memory on these devices then? Is
the driver expected to allocate and map via vm_insert_page()?

> Hot-unplug:
> 
>    Some devices can't necessarily handle unexpected migration, and
>    hot-unplug is fundamentally a migration.  So the HOTUNPLUG cap
>    actually means "hot-unplug can execute migrations".
> 
>    If the entire device has pre-drained the memory (all memory is free)
>    then unplug works - it's just not very hot (no migrations) :]
> 
>    Maybe a naming issue?
> 

Yes, I would prefer MIGRATION in the name, HOTUNPLUG made me wonder how these
devices come online and because it is a device, it can go offline while the
system is still online

> ~Gregory
> 

Balbir
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.