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

[David Hildenbrand (Red Hat)]

On 1/6/26 17:58, Gregory Price wrote:
> On Tue, Jan 06, 2026 at 04:24:21PM +0100, David Hildenbrand (Red Hat) wrote:
> > > +/*
> > > + * Restrict hotplugged memory blocks to ZONE_MOVABLE only.
> > > + *
> > > + * During offlining of hotplugged memory which was originally onlined
> > > + * as ZONE_MOVABLE, userland services may detect blocks going offline
> > > + * and automatically re-online them into ZONE_NORMAL or lower.  When
> > > + * this happens it may become permanently incapable of being removed.
> >
> > If it's really only that, we could also look into simply making a re-online
> > without a specific mode ("online") to use the previous mode.
> >
> > We could glue that to the "contig-zones" policy only, to not affect
> > "auto-movable".
> >
> > That is, remember the zone to which it was previously onlined, and then
> > simply re-online to that one.
>
> I know we do this in memory_hotplug.c to rollback to prior state.
>
> I did notice in... i think it was either memory.c or hotplug.c... that
> we end up setting mem->online_type=MMOP_OFFLINE after comping an online
> operation.  That seemed confusing and maybe we can use that to store the
> current state.
>
> 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?

> 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.

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

> 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).

--
Cheers

David