qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 00/15] qcow/qcow2 cleanups


From: Frediano Ziglio
Subject: Re: [Qemu-devel] [PATCH v2 00/15] qcow/qcow2 cleanups
Date: Tue, 23 Aug 2011 16:00:39 +0200

2011/8/22 Kevin Wolf <address@hidden>:
> Am 09.08.2011 09:46, schrieb Frediano Ziglio:
>> These patches mostly cleanup some AIO code using coroutines.
>> Mostly they use stack instead of allocated AIO structure.
>> Feel free to collapse it too short.
>>
>> Frediano Ziglio (15):
>>   qcow: allocate QCowAIOCB structure using stack
>>   qcow: QCowAIOCB field cleanup
>>   qcow: move some blocks of code to avoid useless variable
>>     initialization
>>   qcow: embed qcow_aio_read_cb into qcow_co_readv and qcow_aio_write_cb
>>     into qcow_co_writev
>>   qcow: remove old #undefined code
>>   qcow2: removed unused fields
>>   qcow2: removed cur_nr_sectors field in QCowAIOCB
>>   qcow2: remove l2meta from QCowAIOCB
>>   qcow2: remove cluster_offset from QCowAIOCB
>>   qcow2: remove common from QCowAIOCB
>>   qcow2: reindent and use while before the big jump
>>   qcow2: removed QCowAIOCB entirely
>>   qcow2: remove memory leak
>>   qcow2: small math optimization
>>   qcow2: small optimization
>>
>>  block/qcow.c           |  378 ++++++++++++++------------------------------
>>  block/qcow2-refcount.c |   16 +--
>>  block/qcow2.c          |  412 
>> +++++++++++++++++++----------------------------
>>  3 files changed, 294 insertions(+), 512 deletions(-)
>
> Can you please rebase this series to current master? I expect that most
> conflicts are related to the qemu_malloc -> g_malloc change, so they
> should be easy to fix.
>

Done, yes glib rename was the problem. I rebased all patches and
tested latest with iotests.

> One thing I noticed when reading the first two patches is that there is
> some state in ACBs that previously was shared across multiple requests
> (e.g. the bounce buffer for encryption). It is no longer shared after
> you move the ACB to the stack, so each request allocates a new buffer.
> Have you checked if this makes a noticeable difference in performance
> for encrypted images?
>
> Kevin
>

I didn't test encrypt performance. Looking at master code the only
cached state that get reused is cluster_data so only encryption is
affected.

Frediano



reply via email to

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