From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Gregory Price <gourry@gourry.net>, linux-mm@kvack.org
Cc: linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev,
linux-kernel@vger.kernel.org, virtualization@lists.linux.dev,
kernel-team@meta.com, dan.j.williams@intel.com,
vishal.l.verma@intel.com, dave.jiang@intel.com, mst@redhat.com,
jasowang@redhat.com, xuanzhuo@linux.alibaba.com,
eperezma@redhat.com, osalvador@suse.de,
akpm@linux-foundation.org
Subject: Re: [PATCH 7/8] dax/kmem: add sysfs interface for runtime hotplug state control
Date: Wed, 14 Jan 2026 11:55:21 +0100 [thread overview]
Message-ID: <3555385d-23de-492c-8192-a991f91d4343@kernel.org> (raw)
In-Reply-To: <20260114085201.3222597-8-gourry@gourry.net>
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?
It would be a lot simpler if we would only allow
> - "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
That is, transitioning from offline to online or vice versa fails with
-ENOSUPP. User space can do that itself through sysfs and if there is
ever a good use case we can extend this interface here to allow it.
Or is there a good use case that really requires this?
--
Cheers
David
next prev parent reply other threads:[~2026-01-14 10:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 8:51 Subject: [PATCH 0/8] dax/kmem: add " Gregory Price
2026-01-14 8:51 ` [PATCH 1/8] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-01-14 9:46 ` David Hildenbrand (Red Hat)
2026-01-14 8:51 ` [PATCH 2/8] mm/memory_hotplug: extract __add_memory_resource() and __offline_memory() Gregory Price
2026-01-14 10:14 ` David Hildenbrand (Red Hat)
2026-01-14 8:51 ` [PATCH 3/8] mm/memory_hotplug: add APIs for explicit online type control Gregory Price
2026-01-14 10:21 ` David Hildenbrand (Red Hat)
2026-01-14 8:51 ` [PATCH 4/8] mm/memory_hotplug: return online type from add_memory_driver_managed() Gregory Price
2026-01-14 10:49 ` David Hildenbrand (Red Hat)
2026-01-14 8:51 ` [PATCH 5/8] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-01-14 8:51 ` [PATCH 6/8] dax/kmem: add online/offline " Gregory Price
2026-01-14 8:51 ` [PATCH 7/8] dax/kmem: add sysfs interface for runtime hotplug state control Gregory Price
2026-01-14 10:55 ` David Hildenbrand (Red Hat) [this message]
2026-01-14 8:52 ` [PATCH 8/8] dax/kmem: add memory notifier to block external state changes Gregory Price
2026-01-14 9:44 ` David Hildenbrand (Red Hat)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3555385d-23de-492c-8192-a991f91d4343@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=eperezma@redhat.com \
--cc=gourry@gourry.net \
--cc=jasowang@redhat.com \
--cc=kernel-team@meta.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mst@redhat.com \
--cc=nvdimm@lists.linux.dev \
--cc=osalvador@suse.de \
--cc=virtualization@lists.linux.dev \
--cc=vishal.l.verma@intel.com \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox