From: Sumanth Korikkar <sumanthk@linux.ibm.com>
To: Karel Zak <kzak@redhat.com>, util-linux@vger.kernel.org
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Sumanth Korikkar <sumanthk@linux.ibm.com>
Subject: [PATCH v2 0/6] chmem/lsmem: dynamic (de)configuration of memory
Date: Thu, 16 Oct 2025 17:38:00 +0200 [thread overview]
Message-ID: <20251016153808.3565873-1-sumanthk@linux.ibm.com> (raw)
Hi all,
Patchset extends chmem and lsmem with support for dynamically configuring and
deconfiguring hotpluggable memory blocks on s390, including per-block
memmap-on-memory handling.
On s390, the memmap-on-memory feature was
introduced to ensure that the struct page array (metadata) for hotpluggable
standby memory can be allocated from the memory block itself. This allowed
hot-add operations even under memory pressure, especially in systems with an
imbalance between boot-time online memory and standby memory.
The original implementation had few limitations:
* All hotpluggable standby memory was added at boot, making blocks
visible for online/offline operations earlier.
* The use of memmap-on-memory was global and static, decided at boot
time. Either all standby blocks used it, or none of them did.
* memmap-on-memory choice could not be changed at runtime, limiting
flexibility.
The s390 kernel (linux-next) ff18dcb19aab ("s390/sclp: Add support for
dynamic (de)configuration of memory") no longer pre-adds all standby
memory at boot. Instead, users must explicitly configure a block before
it can be used for online/offline actions. At configuration time, users
can dynamically decide whether to use optional memmap-on-memory for each
memory block, where value of 1 allocates metadata (such as struct pages
array) from the hotplug memory itself, enabling hot-add operations even
under memory pressure. A value of 0 stores metadata in regular system
memory and enables continuous physical memory across memory blocks.
Kernel changes for dynamic (de)configuration of memory (available on
linux-next):
https://lore.kernel.org/all/20251010085147.2175918-1-sumanthk@linux.ibm.com/
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/s390/char/sclp_mem.c
The kernel sysfs interface provides configuration and memmap-on-memory toggling:
echo 1 > /sys/firmware/memory/memoryX/config – configure block
echo 0 > /sys/firmware/memory/memoryX/config – deconfigure block
echo 1 > /sys/firmware/memory/memoryX/memmap_on_memory – enable memmap-on-memory
echo 0 > /sys/firmware/memory/memoryX/memmap_on_memory – disable memmap-on-memory
Patchset teaches chmem and lsmem to make use of these interfaces, mirroring
existing online/offline semantics:
chmem -c 128M -m 1 : configure memory with memmap-on-memory
chmem -g 128M : deconfigure memory
chmem -e 128M : configure (if supported by architecture) and online memory
chmem -d 128M : offline and deconfigure memory (if supported by
architecture)
lsmem -o RANGE,SIZE,STATE,BLOCK,CONFIGURED,MEMMAP-ON-MEMORY
memmap-on-memory can only be toggled when a block is in a deconfigured state,
and is supported via the --configure option.
v2 (Thanks Karel):
* lsmem:
* Use _PATH_SYS_MEMMAP_PARM instead of const char *path.
* Use N_()/_() in get_memmap_mode()/printf().
* Improve skip_memconfig_column().
* Check /sys/firmware/memory/memory0 existance before read_basic_info().
The latter can run after column setup. Doing so reduces
ul_path_access(lsmem->sysmemconfig, F_OK, 'memory0') calls to just one.
* chmem:
* Rename chmem_memmap_on_memory_option_enabled() to chmem_memmap_enabled().
* Improve configure check in warn().
* Optimization in chmem_set_memmap_on_memory().
* Remove "\n" in warn().
* Add _() when printing info.
Sumanth Korikkar (6):
lsmem: display global memmap on memory parameter
lsmem: add support to display dynamic (de)configuration of memory
chmem: add support for dynamic (de)configuration of hotplug memory
chmem: add chmem documentation for dynamic (de)configuration of memory
lsmem: add doc for dynamic (de)configuration and memmap-on-memory
support
lsmem,chmem: add configure/deconfigure bash completion options
bash-completion/chmem | 3 +
bash-completion/lsmem | 2 +-
sys-utils/chmem.8.adoc | 47 +++++-
sys-utils/chmem.c | 371 +++++++++++++++++++++++++++++++++++++----
sys-utils/lsmem.1.adoc | 46 ++++-
sys-utils/lsmem.c | 136 +++++++++++++--
6 files changed, 555 insertions(+), 50 deletions(-)
--
2.41.0
next reply other threads:[~2025-10-16 15:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 15:38 Sumanth Korikkar [this message]
2025-10-16 15:38 ` [PATCH v2 1/6] lsmem: display global memmap on memory parameter Sumanth Korikkar
2025-10-16 15:38 ` [PATCH v2 2/6] lsmem: add support to display dynamic (de)configuration of memory Sumanth Korikkar
2025-10-16 15:38 ` [PATCH v2 3/6] chmem: add support for dynamic (de)configuration of hotplug memory Sumanth Korikkar
2025-10-16 15:38 ` [PATCH v2 4/6] chmem: add chmem documentation for dynamic (de)configuration of memory Sumanth Korikkar
2025-10-16 15:38 ` [PATCH v2 5/6] lsmem: add doc for dynamic (de)configuration and memmap-on-memory support Sumanth Korikkar
2025-10-16 15:38 ` [PATCH v2 6/6] lsmem,chmem: add configure/deconfigure bash completion options Sumanth Korikkar
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=20251016153808.3565873-1-sumanthk@linux.ibm.com \
--to=sumanthk@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).