[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH 0/1] RFC: don't obey the block device max transf

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH 0/1] RFC: don't obey the block device max transfer len / max segments for block devices
Date: Wed, 3 Jul 2019 09:46:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 7/3/19 4:52 AM, Stefan Hajnoczi wrote:
> On Sun, Jun 30, 2019 at 06:08:54PM +0300, Maxim Levitsky wrote:
>> It looks like Linux block devices, even in O_DIRECT mode don't have any user 
>> visible
>> limit on transfer size / number of segments, which underlying block device 
>> can have.
>> The block layer takes care of enforcing these limits by splitting the bios.

s/The block layer/The kernel block layer/

>> By limiting the transfer sizes, we  force qemu to do the splitting itself 
>> which

double space

>> introduces various overheads.
>> It is especially visible in nbd server, where the low max transfer size of 
>> the
>> underlying device forces us to advertise this over NBD, thus increasing the 
>> traffic overhead in case of

Long line for a commit message.

>> image conversion which benefits from large blocks.
>> More information can be found here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1647104
>> Tested this with qemu-img convert over nbd and natively and to my surprise, 
>> even native IO performance improved a bit.
>> (The device on which it was tested is Intel Optane DC P4800X, which has 128k 
>> max transfer size)
>> The benchmark:

I'm sorry I didn't see this before softfreeze, but as a performance
improvement, I think it still classes as a bug fix and is safe for
inclusion in rc0.

>> The block limits of max transfer size/max segment size are retained
>> for the SCSI passthrough because in this case the kernel passes the 
>> userspace request
>> directly to the kernel scsi driver, bypassing the block layer, and thus 
>> there is no code to split
>> such requests.
>> What do you think?

Seems like a reasonable explanation.

>> Fam, since you was the original author of the code that added
>> these limits, could you share your opinion on that?
>> What was the reason besides SCSI passthrough?
>> Best regards,
>>      Maxim Levitsky
>> Maxim Levitsky (1):
>>   raw-posix.c - use max transfer length / max segemnt count only for
>>     SCSI passthrough
>>  block/file-posix.c | 16 +++++++---------
>>  1 file changed, 7 insertions(+), 9 deletions(-)
> Adding Eric Blake, who implemented the generic request splitting in the
> block layer and may know if there were any other reasons aside from SCSI
> passthrough why file-posix.c enforces the host block device's maximum
> transfer size.

No, I don't have any strong reasons for why file I/O must be capped to a
specific limit other than size_t (since the kernel does just fine at
splitting things up).

> Reviewed-by: Stefan Hajnoczi <address@hidden>

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]