Re: [Qemu-devel] [RFC PATCH V3] qemu-img: make convert async

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

[meta-comment]

On 02/14/2017 02:43 PM, Peter Lieven wrote:
> 
> 
> 
> 
>  Von:   Kevin Wolf <kwolf@redhat.com> 
>  An:   Peter Lieven <pl@kamp.de> 
>  Kopie:   <qemu-devel@nongnu.org>, <qemu-block@nongnu.org>, <mreitz@redhat.com>, <ct@flyingcircus.io> 
>  Gesendet:   14.02.2017 17:20 
>  Betreff:   Re: [RFC PATCH V3] qemu-img: make convert async 
> 
> Am 14.02.2017 um 14:39 hat Peter Lieven geschrieben: 
>> this is something I have been thinking about for almost 2 years now. 

Your quoting style did not introduce any extra prefix in front of
Kevin's comments...

>> we heavily have the following two use cases when using qemu-img convert. 
>> +    int nb_sectors; 
>> +    QSIMPLEQ_ENTRY(ImgConvertRequest) next; 
>> +} ImgConvertRequest; 
>  
> If I understand your code correctly, you first go through the image and 
> create an ImgConvertRequest for every chunk with the same allocation 
> status (well, actually not every chunk, but that may be a bug, see 
> below). 
>  
> So let's assume a 1 TB image with every other cluster allocated: 
>  
>     1T / (64k * 2) = 8M 
>  
> A list with 8 million entries (requiring 8 million mallocs) feels 
> relatively large. Not counting malloc overhead (which might be 
> considerable here), I think we're at 192 MB memory usage for this case. 
> Not as bad as I was afraid, but not really nice either. And 1 TB isn't 
> even close to the maximum image size. 
>  
> Is it really necessary to create this list at the beginning? Why can't 
> we just get the next chunk as the old code used to? 
> 
> 
> In my initial version with AIO invoking convert_iterate_sectors caused

...with the VERY annoying effect that it is now impossible to tell the
difference between what Kevin wrote and what you wrote.  Please consider
improving your mail flow to use a mailer that properly inserts '>'
prefixes in front of quoted lines, to make it easier to call attention
to the lines that you are adding to the conversation.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]