From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqlBA-0005X0-6i for qemu-devel@nongnu.org; Mon, 26 Oct 2015 13:03:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqlB6-0001aV-Tz for qemu-devel@nongnu.org; Mon, 26 Oct 2015 13:03:28 -0400 Received: from mail-pa0-x22c.google.com ([2607:f8b0:400e:c03::22c]:35172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqlB6-0001aA-IE for qemu-devel@nongnu.org; Mon, 26 Oct 2015 13:03:24 -0400 Received: by pasz6 with SMTP id z6so193487385pas.2 for ; Mon, 26 Oct 2015 10:03:24 -0700 (PDT) Sender: Paolo Bonzini References: <562E48B9.6090600@redhat.com> <562E56B8.2030109@redhat.com> From: Paolo Bonzini Message-ID: <562E5CD4.8010902@redhat.com> Date: Mon, 26 Oct 2015 18:03:16 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] 4k seq read splitting for virtio-blk - possible workarounds? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrey Korolyov Cc: Sergey Fionov , Jens Axboe , Jeff Moyer , Peter Lieven , "qemu-devel@nongnu.org" On 26/10/2015 17:43, Andrey Korolyov wrote: > On Mon, Oct 26, 2015 at 7:37 PM, Paolo Bonzini wrote: >> On 26/10/2015 17:31, Andrey Korolyov wrote: >>>> 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. >>>> >>>> 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 >> ^^^^^^^^^^ >> >> queued you mean? >> >>> 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? >> >> This is probably the fall-out of converting the virtio-blk to use >> blk-mq, which was premature to say the least. Jeff Moyer was working on >> it, but I'm not sure if this has been merged. Andrey, what kernel are >> you using? > > Queued, sorry for honest mistype, guest kernel is a 3.16.x from > jessie, so regular blk-mq is there. Any point of interest for trying > something newer? And of course I didn`t thought about something older, > will try against 3.10 now. Yes, it makes sense to try both something older and something newer. I found this: commit e6c4438ba7cb615448492849970aaf0aaa1cc973 Author: Jeff Moyer Date: Fri May 8 10:51:30 2015 -0700 blk-mq: fix plugging in blk_sq_make_request Looking at the meat of the patch, we have: const int is_sync = rw_is_sync(bio->bi_rw); const int is_flush_fua = bio->bi_rw & (REQ_FLUSH | REQ_FUA); - unsigned int use_plug, request_count = 0; + struct blk_plug *plug; + unsigned int request_count = 0; struct blk_map_ctx data; struct request *rq; - /* - * If we have multiple hardware queues, just go directly to - * one of those for sync IO. - */ - use_plug = !is_flush_fua && !is_sync; For reads rw_is_sync returns true, hence use_plug is always false. So 4.2 kernels could fix this issue. Paolo