Message-ID: <57c5f44f-3921-478b-843b-877fae536591@kernel.org>
Date: Thu, 22 Jan 2026 23:49:48 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org, linux-cxl@...r.kernel.org, nvdimm@...ts.linux.dev,
 linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
 kernel-team@...a.com, dan.j.williams@...el.com, vishal.l.verma@...el.com,
 dave.jiang@...el.com, mst@...hat.com, jasowang@...hat.com,
 xuanzhuo@...ux.alibaba.com, eperezma@...hat.com, osalvador@...e.de,
 akpm@...ux-foundation.org
Subject: Re: [PATCH 7/8] dax/kmem: add sysfs interface for runtime hotplug
 state control

On 1/14/26 19:11, Gregory Price wrote:
> On Wed, Jan 14, 2026 at 11:55:21AM +0100, David Hildenbrand (Red Hat) wrote:
>> On 1/14/26 09:51, Gregory Price wrote:
>>> The dax kmem driver currently onlines memory automatically during
>>> probe using the system's default online policy but provides no way
>>> to control or query the memory state at runtime. Users cannot change
>>> the online type after probe, and there's no atomic way to offline and
>>> remove memory blocks together.
>>>
>>> Add a new 'hotplug' sysfs attribute that allows userspace to control
>>> and query the memory state. The interface supports the following states:
>>>
>>>     - "offline": memory is added but not online
>>>     - "online": memory is online as normal system RAM
>>>     - "online_movable": memory is online in ZONE_MOVABLE
>>>     - "unplug": memory is offlined and removed
>>>
>>> The initial state after probe uses MMOP_SYSTEM_DEFAULT to preserve
>>> backwards compatibility - existing systems with auto-online policies
>>> will continue to work as before.
>>>
>>> The state machine enforces valid transitions:
>>>     - From offline: can transition to online, online_movable, or unplug
>>>     - From online/online_movable: can transition to offline or unplug
>>>     - Cannot switch directly between online and online_movable
>>
>> Do we have to support these transitions right from the start?
>>
>> What are the use cases for adding memory as offline and then onlining it,
>> and why do we have to support that through this interface?
>>
> 
> After a re-read of the feedback - are you suggested to basically kill the
> entire offline state of blocks entirely? (e.g. if a driver calls to
> offline a block, instead fully unplug it)

I'm merely wondering why, in the new world, you would even want the 
offline state.

So what are the use cases for that?


Sure, memory onlining can (in debug configs) fail, so you can maneuver 
yourself into a position where some memory is online and other is offline.

But "unfortunately having some memory blocks offline" is something 
different then user space explicitly asking to "keep all of it offline".

Why would user space possibly want that?

> 
> I took a look at the acpi and ppc code you suggested, and I think they
> also have "expect offline then online" as a default expectation.  I
> can't speak to those users requirements.

That's because the policy is defined by user space, and in contrast to 
CXL, hotplug of APPI is *not* triggered by user space, but by hardware / 
hypervisor.

> 
> This would definitely break things like daxctl/ndctl, but maybe that's
> preferable?  I pointed out that patch 8 does this anyway - and I'd like
> input from ndctl folks as to whether that should end in a NACK.

You mean that it would break the ndctl option to keep memory offline?

Can't ndctl just use the old (existing) interface if such an operation 
is requested, and the new one (you want to add) when we want to do 
something reasonable (actually use system ram? :) ).

-- 
Cheers

David

Powered by blists - more mailing lists