[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9575e042-39f4-4f01-80db-34aaaa9312e6@kernel.org>
Date: Tue, 6 Jan 2026 18:52:11 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
osalvador@...e.de, gregkh@...uxfoundation.org, rafael@...nel.org,
dakr@...nel.org, akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com,
Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
mhocko@...e.com, hare@...e.de
Subject: Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory
blocks to zone movable
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
Powered by blists - more mailing lists