From nobody Mon Feb 9 15:09:34 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1599820579; cv=none; d=zohomail.com; s=zohoarc; b=fi/W+aJUQ2rIuKvgr7fCX2TbWe8EYoBj+jkv/Cb0sieRc/QU7xpMKeDZ47LueXOawXJVInd9VNVJU64BXY5eMDLM5ZJu0hjJP70zaylZ5bFU4/t+deaE+lrxd12JLe3rQX2KDNQxXfhDb3ygD2RbtWsOcEh4NsZwaKvLbGoIGak= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1599820579; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=Ilu5qA/4MOIRMjHNcFmuyfPNfVkDyJXmY7w9sBJwUqM=; b=G+x/8Yvn4BlpVQQieDKGUVwa1RfiXGHFjZQDumx+yYk9Yzes7Y7KQ18oayFfBEtEZF6MizAPdo37pbM7wqNlIcg4XieLOX+Vcyr1RNqirR3LmGXd/9D42Wg+PRIihRKmsrN46pPCzTH37xiMmIhDIj1Af8kanh/i4QI/Hcf3wuQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1599820579492479.52550413349; Fri, 11 Sep 2020 03:36:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kGgPV-0002RL-6U; Fri, 11 Sep 2020 10:36:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kGgPT-0002QH-UF for xen-devel@lists.xenproject.org; Fri, 11 Sep 2020 10:36:03 +0000 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 8040dd64-da73-4e27-8899-feb6227a2b63; Fri, 11 Sep 2020 10:36:03 +0000 (UTC) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-475-i_fYLb3wO1GbagxD_riIhw-1; Fri, 11 Sep 2020 06:35:59 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F1481873084; Fri, 11 Sep 2020 10:35:56 +0000 (UTC) Received: from t480s.redhat.com (ovpn-113-186.ams2.redhat.com [10.36.113.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id D526C81C44; Fri, 11 Sep 2020 10:35:53 +0000 (UTC) X-Inumbo-ID: 8040dd64-da73-4e27-8899-feb6227a2b63 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599820563; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ilu5qA/4MOIRMjHNcFmuyfPNfVkDyJXmY7w9sBJwUqM=; b=D2BW2evt5fiDxV+jvaH2Ji9wgP6NH0Xj/zJ+htnGEsn7E3sxYsHZHwimuHe5nvzW4ZsS0u OI7oBFoBqVGa5IDEnqsJ0UrMP9YCTfNpSHq+7H6MlOjj4x1+FdMVqYthxlNQBlpmnPk/l9 NSJg3h0HuXWx9SYbgNeuWU/IzKC6Blc= X-MC-Unique: i_fYLb3wO1GbagxD_riIhw-1 From: David Hildenbrand 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, linux-acpi@vger.kernel.org, linux-nvdimm@lists.01.org, linux-s390@vger.kernel.org, Andrew Morton , David Hildenbrand , Pankaj Gupta , Michal Hocko , Dan Williams , "Michael S . Tsirkin" , Jason Wang , Baoquan He , Wei Yang Subject: [PATCH v4 6/8] virtio-mem: try to merge system ram resources Date: Fri, 11 Sep 2020 12:34:57 +0200 Message-Id: <20200911103459.10306-7-david@redhat.com> In-Reply-To: <20200911103459.10306-1-david@redhat.com> References: <20200911103459.10306-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" virtio-mem adds memory in memory block granularity, to be able to remove it in the same granularity again later, and to grow slowly on demand. This, however, results in quite a lot of resources when adding a lot of memory. 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 later when e.g., trying to create a kdump header). Before this patch, we get (/proc/iomem) when hotplugging 2G via virtio-mem on x86-64: [...] 100000000-13fffffff : System RAM 140000000-33fffffff : virtio0 140000000-147ffffff : System RAM (virtio_mem) 148000000-14fffffff : System RAM (virtio_mem) 150000000-157ffffff : System RAM (virtio_mem) 158000000-15fffffff : System RAM (virtio_mem) 160000000-167ffffff : System RAM (virtio_mem) 168000000-16fffffff : System RAM (virtio_mem) 170000000-177ffffff : System RAM (virtio_mem) 178000000-17fffffff : System RAM (virtio_mem) 180000000-187ffffff : System RAM (virtio_mem) 188000000-18fffffff : System RAM (virtio_mem) 190000000-197ffffff : System RAM (virtio_mem) 198000000-19fffffff : System RAM (virtio_mem) 1a0000000-1a7ffffff : System RAM (virtio_mem) 1a8000000-1afffffff : System RAM (virtio_mem) 1b0000000-1b7ffffff : System RAM (virtio_mem) 1b8000000-1bfffffff : System RAM (virtio_mem) 3280000000-32ffffffff : PCI Bus 0000:00 With this patch, we get (/proc/iomem): [...] fffc0000-ffffffff : Reserved 100000000-13fffffff : System RAM 140000000-33fffffff : virtio0 140000000-1bfffffff : System RAM (virtio_mem) 3280000000-32ffffffff : PCI Bus 0000:00 Of course, with more hotplugged memory, it gets worse. When unplugging memory blocks again, try_remove_memory() (via offline_and_remove_memory()) will properly split the resource up again. Reviewed-by: Pankaj Gupta Cc: Andrew Morton Cc: Michal Hocko Cc: Dan Williams Cc: Michael S. Tsirkin Cc: Jason Wang Cc: Pankaj Gupta Cc: Baoquan He Cc: Wei Yang Signed-off-by: David Hildenbrand Reviewed-by: Wei Yang --- drivers/virtio/virtio_mem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c index ed99e43354010..ba4de598f6636 100644 --- a/drivers/virtio/virtio_mem.c +++ b/drivers/virtio/virtio_mem.c @@ -424,7 +424,8 @@ static int virtio_mem_mb_add(struct virtio_mem *vm, uns= igned long mb_id) =20 dev_dbg(&vm->vdev->dev, "adding memory block: %lu\n", mb_id); return add_memory_driver_managed(nid, addr, memory_block_size_bytes(), - vm->resource_name, MHP_NONE); + vm->resource_name, + MEMHP_MERGE_RESOURCE); } =20 /* --=20 2.26.2