qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qcow2: allocate cluster_cache/cluster_data on d


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] qcow2: allocate cluster_cache/cluster_data on demand
Date: Fri, 18 Aug 2017 10:18:37 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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 <address@hidden>
> Cc: Kevin Wolf <address@hidden>
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
> Alexey: Does this improve your memory profiling results?

Is this a regression from earlier versions?  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?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]