|
From: | Peter Lieven |
Subject: | Re: [Qemu-devel] [PATCH 1.8 3/6] qemu-img: add option to specify alternate iobuffer size |
Date: | Mon, 25 Nov 2013 16:24:32 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |