Re: [PATCH v5 0/5] qcow2: async handling of fragmented io

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

20.09.2019 14:10, Max Reitz wrote:
> On 16.09.19 19:53, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> Here is an asynchronous scheme for handling fragmented qcow2
>> reads and writes. Both qcow2 read and write functions loops through
>> sequential portions of data. The series aim it to parallelize these
>> loops iterations.
>> It improves performance for fragmented qcow2 images, I've tested it
>> as described below.
> 
> Thanks again, applied to my block branch:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Thanks a lot!

> 
>> v5: fix 026 and rebase on Max's block branch [perf results not updated]:
>>
>> 01: new, prepare 026 to not fail
>> 03: - drop read_encrypted blkdbg event [Kevin]
>>      - assert((x & (BDRV_SECTOR_SIZE - 1)) == 0) -> assert(QEMU_IS_ALIGNED(x, BDRV_SECTOR_SIZE)) [rebase]
>>      - full host offset in argument of qcow2_co_decrypt [rebase]
>> 04: - substitute remaining qcow2_co_do_pwritev by qcow2_co_pwritev_task in comment [Max]
>>      - full host offset in argument of qcow2_co_encrypt [rebase]
>> 05: - Now patch don't affect 026 iotest, so its output is not changed
>>
>> Rebase changes seems trivial, so, I've kept r-b marks.
> 
> (For the record, I didn’t consider them trivial, or I’d’ve applied
> Maxim’s series on top of yours.  I consider a conflict to be trivially
> resolvable only if there is only one way of doing it; but when I
> resolved the conflicts myself, I resolved the one in patch 3 differently
> from you – I added an offset_in_cluster variable to
> qcow2_co_preadv_encrypted().  Sure, it’s still simple and the difference
> is minor, but that was exactly where I thought that I can’t consider
> this trivial.)
> 

Hmm. May be it's trivial enough to keep r-b (as my change is trivial itself), but not
trivial enough to change alien patch on queuing? If you disagree, I'll be more
careful on keeping r-b in changed patches, sorry.


-- 
Best regards,
Vladimir