util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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).