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
