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)
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?
~Gregory
