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: Subject: [PATCH 0/8] dax/kmem: add runtime hotplug state control
Date: Wed, 14 Jan 2026 03:51:52 -0500 [thread overview]
Message-ID: <20260114085201.3222597-1-gourry@gourry.net> (raw)
This series adds the ability for the dax_kmem driver to control the
online/offline state of its entire memory region at runtime through a
single sysfs interface. This eliminates the need to manually iterate
over individual memory blocks when changing memory state.
Problem
=======
The dax_kmem driver currently provides no runtime control over memory
state after probe. Memory is automatically onlined using the system
default policy, and any subsequent state changes require userspace to:
1. Enumerate all memory blocks backing the dax region
2. Individually offline/online each block via
/sys/devices/system/memory/memoryXXX/state
3. Handle races with auto-online policies that may re-online blocks
4. Coordinate offline+remove operations across multiple blocks
This is error-prone and creates race conditions between userspace
operations and kernel memory policies. There is no atomic way to
offline and remove an entire dax region, and no mechanism to prevent
external interference with driver-managed memory.
Solution
========
This series introduces a 'hotplug' sysfs attribute for dax devices that
provides atomic control over the entire memory region:
/sys/bus/dax/devices/<device>/hotplug
The interface accepts 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 driver handles all memory blocks atomically and prevents external
state changes through a memory notifier that blocks operations not
initiated by the driver itself.
Series Organization
===================
Patches 1-4 refactor the mm/memory_hotplug infrastructure:
- Patch 1: Pass online_type to online_memory_block() via arg
- Patch 2: Extract __add_memory_resource() and __offline_memory()
- Patch 3: Add APIs for explicit online type control
- Patch 4: Return online type from add_memory_driver_managed()
Patches 5-8 implement the dax_kmem functionality:
- Patch 5: Extract hotplug/hotremove helper functions
- Patch 6: Add online/offline helper functions
- Patch 7: Add sysfs interface for runtime hotplug state control
- Patch 8: Add memory notifier to block external state changes
Backwards Compatibility
=======================
The driver uses MMOP_SYSTEM_DEFAULT at probe time to preserve existing
behavior. Systems with auto-online policies will continue to work as
before. The new sysfs interface is additive and does not change the
default probe behavior.
Gregory Price (8):
mm/memory_hotplug: pass online_type to online_memory_block() via arg
mm/memory_hotplug: extract __add_memory_resource() and
__offline_memory()
mm/memory_hotplug: add APIs for explicit online type control
mm/memory_hotplug: return online type from add_memory_driver_managed()
dax/kmem: extract hotplug/hotremove helper functions
dax/kmem: add online/offline helper functions
dax/kmem: add sysfs interface for runtime hotplug state control
dax/kmem: add memory notifier to block external state changes
drivers/dax/kmem.c | 645 ++++++++++++++++++++++++++++-----
drivers/virtio/virtio_mem.c | 8 +-
include/linux/memory_hotplug.h | 6 +-
mm/memory_hotplug.c | 139 +++++--
4 files changed, 678 insertions(+), 120 deletions(-)
--
2.52.0
next reply other threads:[~2026-01-14 8:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 8:51 Gregory Price [this message]
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)
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=20260114085201.3222597-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