From: Gregory Price <gourry@gourry.net>
To: 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, david@kernel.org,
mst@redhat.com, jasowang@redhat.com, xuanzhuo@linux.alibaba.com,
eperezma@redhat.com, osalvador@suse.de,
akpm@linux-foundation.org
Subject: [PATCH v2 0/5] add runtime hotplug state control
Date: Wed, 14 Jan 2026 18:50:16 -0500 [thread overview]
Message-ID: <20260114235022.3437787-1-gourry@gourry.net> (raw)
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 entire region state at runtime.
This series adds a sysfs interface to control DAX kmem memory
hotplug state, and refactors the memory_hotplug paths to make it
possible for drivers to request an online type at hotplug time.
Problem
=======
Once dax_kmem onlines memory during probe, there's no mechanism in
the dax driver to:
- Query the current state of the memory region
- Offline and hot-remove memory blocks atomically
- Control online type (ZONE_NORMAL vs ZONE_MOVABLE)
- Prevent external interference with driver-managed memory state
This forces users (such as ndctl) to toggle individual memory blocks
prior to unbinding the dax device, and has lead to some race conditions
between competing hotplug policies.
Solution
========
This series introduces a 'hotplug' sysfs attribute for dax_kmem devices
that allows userspace to control and query memory region state:
/sys/bus/dax/devices/daxN.M/hotplug
Supported states:
- "unplug": memory is offline and blocks are not present
- "online": memory is online as normal system RAM
- "online_movable": memory is online in ZONE_MOVABLE
A memory notifier prevents external operations (auto-online policies,
direct sysfs manipulation) from changing memory state, ensuring the
driver maintains consistent state tracking.
Patches
=======
Patches 1-2 prepare mm/memory_hotplug to allow callers to specify an
explicit online type rather than implicitly using the system default.
Patch 3 refactors dax_kmem to extract hotplug/hotremove helpers,
preparing for the sysfs interface.
Patch 4 adds the 'hotplug' sysfs interface for runtime state control.
Patch 5 adds a memory notifier to prevent external state changes and
maintain consistency between the sysfs interface and actual memory
block state.
Gregory Price (5):
mm/memory_hotplug: pass online_type to online_memory_block() via arg
mm/memory_hotplug: add 'online_type' argument to
add_memory_driver_managed
dax/kmem: extract hotplug/hotremove helper functions
dax/kmem: add sysfs interface for runtime hotplug state control
dax/kmem: add memory notifier to block external state changes
Documentation/ABI/testing/sysfs-bus-dax | 17 +
drivers/dax/kmem.c | 577 ++++++++++++++++++++----
drivers/virtio/virtio_mem.c | 3 +-
include/linux/memory_hotplug.h | 2 +-
mm/memory_hotplug.c | 35 +-
5 files changed, 528 insertions(+), 106 deletions(-)
--
2.52.0
next reply other threads:[~2026-01-14 23:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 23:50 Gregory Price [this message]
2026-01-14 23:50 ` [PATCH v2 1/5] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-01-14 23:50 ` [PATCH v2 2/5] mm/memory_hotplug: add 'online_type' argument to add_memory_driver_managed Gregory Price
2026-01-14 23:50 ` [PATCH v2 3/5] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-01-14 23:50 ` [PATCH v2 4/5] dax/kmem: add sysfs interface for runtime hotplug state control Gregory Price
2026-01-14 23:50 ` [PATCH v2 5/5] dax/kmem: add memory notifier to block external state changes Gregory Price
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=20260114235022.3437787-1-gourry@gourry.net \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=david@kernel.org \
--cc=eperezma@redhat.com \
--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