Re: [Qemu-devel] [PATCH 1.8 3/6] qemu-img: add option to specify alternate iobuffer size

[Peter Lieven <pl@kamp.de>]

On 25.11.2013 16:14, Paolo Bonzini wrote:
> Il 25/11/2013 16:07, Peter Lieven ha scritto:
>>>> since the convert process is basically a sync operation it might
>>>> be benificial in some case to change the hardcoded I/O buffer
>>>> size to an alternate (greater) value.
>>> Do you really need the extra knob?  You can just add to BlockLimits the
>>> optimal transfer length, and use it unconditionally.
>> If you say patch 5 and 3 are ok. What could be done is to remove
>> this knob and increase the iobuf_size to cluster_size if cluster_size
>> is greater.
> Yes, that makes sense because it avoids unnecessary COW.
>
>> I do not want to increase the default iobuf size to anything
>> greater than 2MB. I do not know why this was choosen, but maybe
>> there was a reason for it.
> I think it is fine to increase it to the cluster_size or even to the
> optimal transfer length (new BlockLimits field).
okay scsi speaking:
  bs->bl.optimal_transfer_length = max(iscsilun->bl.opt_xfer_len, iscsilun->bl.opt_unmap_gran) ?

bdi->cluster_size as in Patch 3?
>
>> The storages we use here have a very strange page size of 15MB.
>> If I sent aligned 15MB chunks the performace is about +50% compared
>> to the original qemu-img.
> I think composing the optimal transfer length and optimal unmap
> granularity (cluster_size) will work well:
>
> * clamp maximum size to optimal transfer length.
or increase it if its larger. for the dell equallogic storages we use the opt_unmap_gran
is 15MB!!!
>
> * then, round final sector down to unmap granularity
okay, i will try your modification to only round down the last sector.
would you use bdi->cluster_size or the unmap alignment field from the bs->bl?

Peter