On 02.12.24 09:27, Sumanth Korikkar wrote:
Provide a new interface for dynamic configuration and deconfiguration of
hotplug memory, allowing for mixed altmap and non-altmap support. It is
a follow-up on the discussion with David:
https://lore.kernel.org/all/ee492da8-74b4-4a97-8b24-73e07257f01d@xxxxxxxxxx/
As mentioned in the discussion, advantages of the new interface are:
* Users can dynamically specify which memory ranges should have altmap
support, rather than having it statically enabled or disabled for all
hot-plugged memory.
* In the long term, user could specify a memory range, including
multiple blocks, and whether user wants altmap support for that range.
This could allow for the altmap block grouping, or even variable-sized
blocks, in the future. i.e. "grouping" memory blocks that share a same
altmap located on the first memory blocks in the group and reduce
fragementation due to altmap.
To leverage these advantages:
Create a sysfs interface /sys/bus/memory/devices/configure_memory, which
performs runtime (de)configuration of memory with altmap or non-altmap
support. The interface validates the memory ranges against architecture
specific memory configuration and performs add_memory()/remove_memory().
Dynamic (de)configuration of memory is made configurable via config
CONFIG_RUNTIME_MEMORY_CONFIGURATION.
Hi!
Not completely what I had in mind, especially not that we need something
that generic without any indication of ranges :)
In general, the flow is as follows:
1) Driver detects memory and adds it
2) Something auto-onlines that memory (e.g., udev rule)
For dax/kmem, 1) can be controlled using devdax, and usually it also
tries to take care of 2).
s390x standby storage really is the weird thing here, because it does 1)
and doesn't want 2). It shouldn't do 1) until a user wants to make use
of standby memory.
My thinking was that s390x would expose the standby memory ranges
somewhere arch specific in sysfs. From there, one could simply trigger
the adding (maybe specifying e.g, memmap_on_memory) of selected ranges.
To disable standby memory, one would first offline the memory to then
trigger removal using the arch specific interface. It is very similar to
dax/kmem's way of handling offline+removal.
Now I wonder if dax/kmem could be (ab)used on s390x for standby storage.
Likely a simple sysfs interface could be easier to implement.
--
Cheers,
David / dhildenb
