[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd21ebf7-d016-4729-8d23-a7c0f2a3d8c6@kernel.org>
Date: Tue, 6 Jan 2026 21:22:37 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Gregory Price <gourry@...rry.net>
Cc: hare@...e.de, 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
Subject: Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory
blocks to zone movable
On 1/6/26 20:59, Gregory Price wrote:
> On Tue, Jan 06, 2026 at 07:38:54PM +0100, David Hildenbrand (Red Hat) wrote:
>> On 1/6/26 19:06, Gregory Price wrote:
>>> On Tue, Jan 06, 2026 at 06:52:11PM +0100, David Hildenbrand (Red Hat) wrote:
>>>> On 1/6/26 17:58, Gregory Price wrote:
>>>
>>> Fair, I'll revist this once Hannes gets a chance to chime in.
>>>
>>> This was effective at getting the discussion started though :P
>>
>> Hehe, yes.
>>
>> Another thing to look into would be to provide a way for ndctl to just
>> add+online the memory in one shot, without having to go back to walking
>> memory blocks to online them etc.
>>
>
> I think it's the opposite: offline+remove needing to be done in one step
> while holding the hotplug lock. Right now, I think you have to do
> something like
That's what I note below, yes.
For the udev vs. ndctl race to be handled in a
good way you need add+online be done in one operation.
>
> daxctl offline-memory ...
> daxctl destroy ...
>
> You can't destroy and have it offline the memory for you in one go IIRC.
As noted below, we have offline_and_remove_memory().
I added the comment:
/*
* Try to offline and remove memory. Might take a long time to finish in case
* memory is still in use. Primarily useful for memory devices that logically
* unplugged all memory (so it's no longer in use) and want to offline + remove
* that memory.
*/
Nothing speaks against letting dax use that, but the tricky part is that
offlining might take forever, so one has to be prepared to handle that
(and letting user space cancel the operation).
And for dax devices that consist of multiple ranges, it can be "fun" having
some regions removed and others not.
Something to think about :)
--
Cheers
David
Powered by blists - more mailing lists