On Wed, Sep 3, 2014 at 1:09 AM, Peter Lieven <p...@kamp.de> wrote: > > >> Am 02.09.2014 um 21:30 schrieb Peter Lieven <p...@kamp.de>: >> >> Looking at the code, is it possible that not the guest is causing trouble >> here, but >> multiwrite_merge code? >> >> From what I see the only limit it has when merging requests is the number of >> IOVs. >> >> >> Any thoughts? >> >> Mine are: >> a) Introducing bs->bl.max_request_size and set merge = 0 if the result would >> be too big. Default >> max request size to 32768 sectors (see below). >> b) Hardcoding the limit in multiwrite_merge for now limiting the merged size >> to 16MB (32768 sectors). >> Which is the limit we already use in bdrv_co_discard and >> bdrv_co_write_zeroes if we don't know >> better. > > or c) disabling multiwrite merge for RAW or only iSCSI completely. >
I think (a) would be best. But I would suggest some small modifications: Set the default max to something even smaller, like 256 sectors. This should not have much effect on throughput since the client/initiator can just send several concurrent i/os instead of one large i/o. Also update scsi_disk_emulate_inquiry() so we tell the guest the maximum transfer length for a single i/o so that the guest kernel will break up any huge requests into proper sizes.