Re: [RFC PATCH 1/4] mm/memory_hotplug: Add interface for runtime (de)configuration of memory

David Hildenbrand
2024-12-02T16:55:25Z

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@redhat.com/
>
> 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