On Mon, Oct 26, 2015 at 6:37 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 26/10/2015 12:50, Andrey Korolyov wrote: >> Hi, >> >> during the test against generic storage backend with NBD frontend we >> found that the virtio block device is always splitting a single read >> range request to 4k ones, bringing the overall performance of the >> sequential reads far below virtio-scsi. Random reads are going >> relatively well on small blocks due to small overhead comparing to >> sequential ones and writes are ok in all cases. Multiread slightly >> improves the situation, but it would be nice to see complete >> pass-through of range read requests down to backend without an >> intermediate splitting. >> >> Samples measured on an NBD backend during 128k sequential reads for >> both virtio-blk and virtio-scsi are attached. Please let me know if it >> looks like that I missed something or this behavior is plainly wrong. > > How does the blktrace look like in the guest? >
Yep, thanks for suggestion. It looks now like a pure driver issue: Reads Queued: 11008, 44032KiB Writes Queued: 0, 0KiB Read Dispatches: 11008, 44032KiB Write Dispatches: 0, 0KiB vs Reads Queued: 185728, 742912KiB Writes Queued: 0, 0KiB Read Dispatches: 2902, 742912KiB Write Dispatches: 0, 0KiB Because guest virtio-blk driver lacks *any* blk scheduler management, this is kinda logical. Requests for scsi backend are dispatched in single block-sized chunks as well, but they are mostly merged by a scheduler before being passed to the device layer. Could be there any improvements over the situation except writing an underlay b/w virtio emulator backend and the real storage?
