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.

Reply via email to