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

[Peter Lieven]

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