From patchwork Sat Aug 19 02:46:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexey Kardashevskiy X-Patchwork-Id: 803481 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ozlabs-ru.20150623.gappssmtp.com header.i=@ozlabs-ru.20150623.gappssmtp.com header.b="d+geqtvj"; dkim-atps=neutral Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3xZ49X48Mhz9t2y for ; Sat, 19 Aug 2017 12:47:11 +1000 (AEST) Received: from localhost ([::1]:34637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ditms-0003yW-IS for incoming@patchwork.ozlabs.org; Fri, 18 Aug 2017 22:46:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ditmJ-0003xe-S8 for qemu-devel@nongnu.org; Fri, 18 Aug 2017 22:46:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ditmG-0003Ch-NY for qemu-devel@nongnu.org; Fri, 18 Aug 2017 22:46:23 -0400 Received: from mail-pg0-x242.google.com ([2607:f8b0:400e:c05::242]:33550) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ditmG-0003Bb-CK for qemu-devel@nongnu.org; Fri, 18 Aug 2017 22:46:20 -0400 Received: by mail-pg0-x242.google.com with SMTP id n4so2532875pgn.0 for ; Fri, 18 Aug 2017 19:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ozlabs-ru.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=GYIjjaObRRykCKy4GYF/2sxFqmBWB7oL8BXIVAQ1Q40=; b=d+geqtvjb7bwFSdZ9DzYQ3v2+YWK8ahYpASThOyTZ2Ufp2nsYwLbxRKv1He6G1vDrR qfsnBZFZMXeK/c7jlcV/pzFunghTJsQQXdHb7HE3ehWokhvDPtnbL1fL9qxDlBBGn7NC TFwts9pShSqcGiQnRNJPpWlgIyrDlzqtbYDnTZiDhs1NwBPk9qxCyCYXT7mifrzA38t3 nV/tzLozGAsAA3AtwYHdiPDxLFX5yj8n/RhZ7Dxy08CrUiO/hpbUodFGDd9eqE3P/7b5 0DW7GfzDThXjW4NEM3/Tk1BIAF8OrestvChqIA8Dgvmw1O45ZmtH73j3EjXAX2FEShPc /mcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=GYIjjaObRRykCKy4GYF/2sxFqmBWB7oL8BXIVAQ1Q40=; b=Gz1H+WL+rvldsyd+tiuW+Egpl/1KyG2O8fKS8BPGPtxB3v7X1bgM6lfNFAiGoMsY2V m1a1zLzwDK+Ys5C4mCv/3N6cfwywfzr75JMWgF8lB6qhDqQ8S9SMsSOl1i7761OMBbwt eZVTTAfg3zFDuuUMdBB2ss3qdUSUHRA3j64ZuJg4XWAibL/izapIDTMT/rV/VkmQtabX EyW0iOYerQstP9vpOjm78bV3RQfGhL0im8CCZZpOAyF4wRcbcB8HAVnjAz421HtF+ao/ lv3lHX4NN3lmsUK4KBSpgTyXf06w4H1xUqeD5tQFUcorOq+0cWPKnYYx8FPFhxz0Vsid 3RjA== X-Gm-Message-State: AHYfb5jymghECr+wRCR345I6oAFMexb6Fp90uiCg2WFyWNSI3DBCFKXc zPKBzQnD/ew8L/lb X-Received: by 10.101.76.76 with SMTP id l12mr10168412pgr.161.1503110778650; Fri, 18 Aug 2017 19:46:18 -0700 (PDT) Received: from [192.168.10.22] (124-171-136-142.dyn.iinet.net.au. [124.171.136.142]) by smtp.googlemail.com with ESMTPSA id p5sm11835437pgf.50.2017.08.18.19.46.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 19:46:17 -0700 (PDT) To: Eric Blake , Stefan Hajnoczi , qemu-devel@nongnu.org References: <20170818133118.8650-1-stefanha@redhat.com> <72ab2a83-3da3-a87e-0196-6b4c533e9461@redhat.com> From: Alexey Kardashevskiy Message-ID: <37256b65-cd64-e4ca-4655-b6dc8d780335@ozlabs.ru> Date: Sat, 19 Aug 2017 12:46:11 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <72ab2a83-3da3-a87e-0196-6b4c533e9461@redhat.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c05::242 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [Qemu-devel] [PATCH] qcow2: allocate cluster_cache/cluster_data on demand X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , qemu-block@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" On 19/08/17 01:18, Eric Blake wrote: > On 08/18/2017 08:31 AM, Stefan Hajnoczi wrote: >> Most qcow2 files are uncompressed so it is wasteful to allocate (32 + 1) >> * cluster_size + 512 bytes upfront. Allocate s->cluster_cache and >> s->cluster_data when the first read operation is performance on a >> compressed cluster. >> >> The buffers are freed in .bdrv_close(). .bdrv_open() no longer has any >> code paths that can allocate these buffers, so remove the free functions >> in the error code path. >> >> Reported-by: Alexey Kardashevskiy >> Cc: Kevin Wolf >> Signed-off-by: Stefan Hajnoczi >> --- >> Alexey: Does this improve your memory profiling results? > > Is this a regression from earlier versions? Hm, I have not thought about this. So. I did bisect and this started happening from 9a4c0e220d8a4f82b5665d0ee95ef94d8e1509d5 "hw/virtio-pci: fix virtio behaviour" Before that, the very same command line would take less than 1GB of resident memory. That thing basically enforces virtio-1.0 for QEMU <=2.6 which means that upstream with "-machine pseries-2.6" works fine (less than 1GB), "-machine pseries-2.7" does not (close to 7GB, sometime even 9GB). Then I tried bisecting again, with "scsi=off,disable-modern=off,disable-legacy=on" on my 150 virtio-block devices, started from e266d421490e0 "virtio-pci: add flags to enable/disable legacy/modern" (it added the disable-modern switch) which uses 2GB of memory. I ended up with ada434cd0b44 "virtio-pci: implement cfg capability". Then I removed proxy->modern_as on v2.10.0-rc3 (see below) and got 1.5GB of used memory (yay!) I do not really know how to reinterpret all of this, do you? Note: 1GB..9GB numbers from below are the peak values from valgrind's massif. This is pretty much resident memory used by QEMU process. In my testing I did not enable KVM and I did not start the guest (i.e. used -S). 150 virtio-block devices, 2GB RAM for the guest. Also, while bisecting, I only paid attention if it is 1..2GB or 6..9GB - all tests did fit these 2 ranges, for any given sha1 the amount of memory would be stable but among "good" commits it could change between 1GB and 2GB. "virtio-pci-cfg", @@ -1791,7 +1792,7 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error **errp) memory_region_size(&proxy->modern_bar)); address_space_init(&proxy->modern_as, &proxy->modern_cfg, "virtio-pci-cfg-as"); - +#endif if (proxy->disable_legacy == ON_OFF_AUTO_AUTO) { proxy->disable_legacy = pcie_port ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF; } @@ -1860,10 +1861,10 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error **errp) static void virtio_pci_exit(PCIDevice *pci_dev) { - VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev); + //VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev); msix_uninit_exclusive_bar(pci_dev); - address_space_destroy(&proxy->modern_as); + //address_space_destroy(&proxy->modern_as); } static void virtio_pci_reset(DeviceState *qdev) > Likely, it is NOT -rc4 > material, and thus can wait for 2.11; but it should be fine for -stable > as part of 2.10.1 down the road. > >> +++ b/block/qcow2-cluster.c >> @@ -1516,6 +1516,23 @@ int qcow2_decompress_cluster(BlockDriverState *bs, uint64_t cluster_offset) >> nb_csectors = ((cluster_offset >> s->csize_shift) & s->csize_mask) + 1; >> sector_offset = coffset & 511; >> csize = nb_csectors * 512 - sector_offset; >> + >> + /* Allocate buffers on first decompress operation, most images are >> + * uncompressed and the memory overhead can be avoided. The buffers >> + * are freed in .bdrv_close(). >> + */ >> + if (!s->cluster_data) { >> + /* one more sector for decompressed data alignment */ >> + s->cluster_data = qemu_try_blockalign(bs->file->bs, >> + QCOW_MAX_CRYPT_CLUSTERS * s->cluster_size + 512); >> + if (!s->cluster_data) { >> + return -EIO; > > Is -ENOMEM any better than -EIO here? > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c index 5d14bd6..7ad447a 100644 --- a/hw/virtio/virtio-pci.c +++ b/hw/virtio/virtio-pci.c @@ -1783,6 +1783,7 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error **errp) /* PCI BAR regions must be powers of 2 */ pow2ceil(proxy->notify.offset + proxy->notify.size)); +#if 0 memory_region_init_alias(&proxy->modern_cfg, OBJECT(proxy),