Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp927847pxk; Thu, 10 Sep 2020 02:18:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSMK4q9WNOQoZT22OYOmAXvmPagBxwb9LZSQgWN2bEJARTDZvDQlpwPX4c3o0PRFOeRyjP X-Received: by 2002:a17:906:f6c9:: with SMTP id jo9mr7697636ejb.233.1599729539803; Thu, 10 Sep 2020 02:18:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599729539; cv=none; d=google.com; s=arc-20160816; b=0OfeQz9G/aXgz/oPw2XcTdemesyk8prx56zxx4tvApzzTeQhJ2+QjypG03AqlTYHhj W7JQ8AKjJRnwlaJEhH5FNRp/64XZwRG0SSZdTQwmIoQJjiK6VxF4jPSPLGQW7rPRkq2h NigO3MvjqVPvRU8s60oUV97tBzcQgjkoBq3C6kONcJ56Akg1OncmuWx8Lc+5F1THnnK9 yOV879+wRfgCYl1L7icMUKfJESVzw1c4cQbtRiDwuLMaWRlUGQvVbhxoWv2YT+2hzUHn /aRdMw7vJInMP8k4K44Y4CQKOzd0Mx0Ay3Vjm47gclLA1RPqNmgI+5DJCaXfW+kyCHp9 vNBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=UKbsrpgJcVk/I/seBIDa5mjqSR3CWWtNLQlSkA+xweM=; b=H5DyasrZvMzrdM4DkrqbUQVvmq602kE9ih/Rp8l3K4c3CUwYvWhltRaTjfNY6VNbIf QAeqGVxEbpAw9Wfil9szp9O7s10zm/BbFe5xjkMGndK9PyyOTI9BMmXi02VKmVWe4WnO 5Vke4vZ/eI2pSlAHTZwzZDnmGi51q/ATugJeUoGqFvLVcOMMIZEnZD08ytwxg/3k89zz UkcfqSlABrZDj1vKj2T7c3+i/Idcec2CkcXfDvDeHhYZKTpXd8ERODVzVTC6lB1mfVFJ f5qjvkpY+RJRNU4HIWc/V4KKB+jt1Guk7NvV633EG1kPoAq032n+sA8MmMykT9c9TSWc OSJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JAyRWGLM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o13si3176465edr.482.2020.09.10.02.18.37; Thu, 10 Sep 2020 02:18:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JAyRWGLM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730315AbgIJJPm (ORCPT + 99 others); Thu, 10 Sep 2020 05:15:42 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:48667 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726600AbgIJJOm (ORCPT ); Thu, 10 Sep 2020 05:14:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599729281; 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=UKbsrpgJcVk/I/seBIDa5mjqSR3CWWtNLQlSkA+xweM=; b=JAyRWGLMk215v6zfyz47/3m4wXWwzhy6cE6SGXGIPfY4oGxlhifcBzo7+9Zbxoi0nwtLM9 vJD5N2hciPEMV0mYXUmfoDVeY6hakFXuKOmr27b2tI3szWxDypbPM61pthzePs1Y8MGKbz Ndf3loCYbjtHYlDAe6zDDeyEJoDC6w8= 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-276-4Ir0pFWkOr2SyXBA0eB5IQ-1; Thu, 10 Sep 2020 05:14:39 -0400 X-MC-Unique: 4Ir0pFWkOr2SyXBA0eB5IQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DEF4E18B9F11; Thu, 10 Sep 2020 09:14:37 +0000 (UTC) Received: from t480s.redhat.com (ovpn-113-88.ams2.redhat.com [10.36.113.88]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9B8ED1A8EC; Thu, 10 Sep 2020 09:14:34 +0000 (UTC) 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 , Michal Hocko , Dan Williams , "Michael S . Tsirkin" , Jason Wang , Pankaj Gupta , Baoquan He , Wei Yang Subject: [PATCH v3 5/7] virtio-mem: try to merge system ram resources Date: Thu, 10 Sep 2020 11:13:38 +0200 Message-Id: <20200910091340.8654-6-david@redhat.com> In-Reply-To: <20200910091340.8654-1-david@redhat.com> References: <20200910091340.8654-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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 --- 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, unsigned long mb_id) 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); } /* -- 2.26.2