Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where possible.
Resources are effectively stored in a list-based tree. Having a lot of
resources not only wastes memory, it also makes traversing that tree more
expensive, and makes /proc/iomem explode in size (e.g., requiring
kexec-tools to manually merge resources when creating a kdump header. The
current kexec-tools resource count limit does not allow more than ~100GB
of memory with a memory block size of 128MB on x86-64).
Let's allow to selectively merge resources, speciyfing a parent node and
a resource idendifier string. The memory unplug path will properly split
up merged resources again.
Patch #3 contains a /proc/iomem example. Only tested with virtio-mem.
Note: This gets the job done and is comparably simple. More complicated
approaches would require introducing IORESOURCE_MERGEABLE and extending our
add_memory*() interfaces with a flag, specifying that merging after adding
succeeded is acceptable. I'd like to avoid that complexity and code churn
for now.
David Hildenbrand (5):
kernel/resource: make release_mem_region_adjustable() never fail
kernel/resource: merge_child_mem_resources() to merge memory resources
after adding succeeded
virtio-mem: try to merge "System RAM (virtio_mem)" resources
xen/balloon: try to merge "System RAM" resources
hv_balloon:: try to merge "System RAM" resources
drivers/hv/hv_balloon.c | 3 ++
drivers/virtio/virtio_mem.c | 14 ++++-
drivers/xen/balloon.c | 4 ++
include/linux/ioport.h | 7 ++-
kernel/resource.c | 105 ++++++++++++++++++++++++++++--------
mm/memory_hotplug.c | 22 +-------
6 files changed, 109 insertions(+), 46 deletions(-)
--
2.26.2
