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

["David Hildenbrand (Red Hat)" <david@kernel.org>]

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