Linux-HyperV Archive on lore.kernel.org
 help / color / Atom feed
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
	linux-hyperv@vger.kernel.org, xen-devel@lists.xenproject.org,
	"David Hildenbrand" <david@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Juergen Gross" <jgross@suse.com>,
	"Julien Grall" <julien@xen.org>,
	"Kees Cook" <keescook@chromium.org>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Michal Hocko" <mhocko@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Stephen Hemminger" <sthemmin@microsoft.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Wei Liu" <wei.liu@kernel.org>,
	"Wei Yang" <richardw.yang@linux.intel.com>
Subject: [PATCH RFCv1 0/5] mm/memory_hotplug: selective merging of memory resources
Date: Fri, 31 Jul 2020 11:18:33 +0200
Message-ID: <20200731091838.7490-1-david@redhat.com> (raw)

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


             reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31  9:18 David Hildenbrand [this message]
2020-07-31  9:18 ` [PATCH RFCv1 1/5] kernel/resource: make release_mem_region_adjustable() never fail David Hildenbrand
2020-07-31  9:18 ` [PATCH RFCv1 2/5] kernel/resource: merge_child_mem_resources() to merge memory resources after adding succeeded David Hildenbrand
2020-07-31  9:18 ` [PATCH RFCv1 3/5] virtio-mem: try to merge "System RAM (virtio_mem)" resources David Hildenbrand
2020-07-31 10:40   ` David Hildenbrand
2020-07-31  9:18 ` [PATCH RFCv1 4/5] xen/balloon: try to merge "System RAM" resources David Hildenbrand
2020-07-31  9:18 ` [PATCH RFCv1 5/5] hv_balloon:: " David Hildenbrand

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=20200731091838.7490-1-david@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=haiyangz@microsoft.com \
    --cc=jgg@ziepe.ca \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=keescook@chromium.org \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=richardw.yang@linux.intel.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wei.liu@kernel.org \
    --cc=xen-devel@lists.xenproject.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

Linux-HyperV Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-hyperv/0 linux-hyperv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-hyperv linux-hyperv/ https://lore.kernel.org/linux-hyperv \
		linux-hyperv@vger.kernel.org
	public-inbox-index linux-hyperv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-hyperv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git