From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr0aT-0008Hi-4y for qemu-devel@nongnu.org; Tue, 27 Oct 2015 05:30:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr0aP-0006ZT-WF for qemu-devel@nongnu.org; Tue, 27 Oct 2015 05:30:37 -0400 Received: from mail-pa0-x22f.google.com ([2607:f8b0:400e:c03::22f]:33230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr0aP-0006ZP-Q5 for qemu-devel@nongnu.org; Tue, 27 Oct 2015 05:30:33 -0400 Received: by pabla5 with SMTP id la5so24418464pab.0 for ; Tue, 27 Oct 2015 02:30:33 -0700 (PDT) Sender: Paolo Bonzini References: <562E48B9.6090600@redhat.com> <562E56B8.2030109@redhat.com> <562E5CD4.8010902@redhat.com> <562E63C1.8020802@redhat.com> <20151027020402.GB12940@ad.usersys.redhat.com> From: Paolo Bonzini Message-ID: <562F4433.5080803@redhat.com> Date: Tue, 27 Oct 2015 10:30:27 +0100 MIME-Version: 1.0 In-Reply-To: <20151027020402.GB12940@ad.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Fam Zheng Cc: Jens Axboe , Andrey Korolyov , Peter Lieven , "qemu-devel@nongnu.org" , Jeff Moyer , Sergey Fionov On 27/10/2015 03:04, Fam Zheng wrote: > > My plan is for > > 2.6 to have fine-grained critical sections (patches written, will repost > > during 2.5 hard freeze), 2.7 (unlikely 2.6) to have fine-grained locks, > > and 2.8 or 2.9 to have multiqueue. > > You're talking about virtio-scsi, right? What about virtio-blk? Do you think we > should resume the "fake" virtio-blk multiqueue work on QEMU side? Even both. If you resume the "fake" virtio-blk multiqueue, converting to real multiqueue at the same time as virtio-scsi should be trivial. The difficult part of course is not the device models, it's the block layer... Paolo