Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory blocks to zone movable

[Gregory Price <gourry@gourry.net>]

On Tue, Jan 06, 2026 at 06:52:11PM +0100, David Hildenbrand (Red Hat) wrote:
> On 1/6/26 17:58, Gregory Price wrote:
> > On Tue, Jan 06, 2026 at 04:24:21PM +0100, David Hildenbrand (Red Hat) wrote:
> > 
> > I'm not against this idea, but it also makes the sysfs a little more
> > confusing (`echo online` now does different things based on prior
> > state).
> 
> Right, but only for the contig-zones policy.
> 
> But maybe you really want the default for such memory to be "movable" even
> when not onlined beforehand? So I am not sure if the description of the
> problem here is accurate.
> 
> Isn't one problem also udev racing with ndctl?
> 

Yeah there's a bunch of races, the specific ones mentioned by Hannes i
need to go back and re-listen to the talk.

> > I preferred just failing if the block wasn't compatible with
> > the zone (maybe making it more clear with a dmesg print?)
> 
> The thing is that this block is compatible with the zone, no?
> 
> In a system where you would never want to offline that memory, why should we
> stop someone from onlining it to a kernel zone? I'm sure someone with a
> weird use case will show up later that will complain about this.
> 

Presumably you wouldn't be setting the MHP flag that prevents the blocks
from being onlined in a kernel zone then - in which case this all just
works as intended today.

> But the patch is missing details on who would actually set MHP_MOVABLE_ONLY.
> A user should be posted alongside the core change.
> 

This is fair and probably the obvious immediate user would be a dax
device with some kind of `dax0.0/protect_unplug` feature set.
(With a better name obviuosly).

I will defer to Hannes on his specific use case, but I could see the
CXL-DCD (Dynamic Capacity) set wanting something like this.

> > 
> > Anyway, let me know what your preference is, happy to pivot however.
> 
> Restricting memory to be movable-only to handle a user-space problem as
> described here sounds like the wrong approach to me. You really want the
> default of such memory to be "movable".
> 
> Almost like an optimized "auto-movable" policy :)
> 
> Or a new policy that will respect a provided default (MHP_DEFAULT_MOVABLE).
> 

Fair, I'll revist this once Hannes gets a chance to chime in.

This was effective at getting the discussion started though :P

~Gregory