From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S12GW-0006OE-Np for qemu-devel@nongnu.org; Fri, 24 Feb 2012 16:01:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S12GV-0002J6-Iz for qemu-devel@nongnu.org; Fri, 24 Feb 2012 16:01:20 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:51193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S12GV-0002Ix-Cf for qemu-devel@nongnu.org; Fri, 24 Feb 2012 16:01:19 -0500 Received: by dadp14 with SMTP id p14so3470592dad.4 for ; Fri, 24 Feb 2012 13:01:18 -0800 (PST) Message-ID: <4F47FA99.8050608@codemonkey.ws> Date: Fri, 24 Feb 2012 15:01:13 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F47DEB1.7080009@redhat.com> <4F47E37A.6000702@codemonkey.ws> <4F47F685.5010000@redhat.com> In-Reply-To: <4F47F685.5010000@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] converting the block layer from coroutines to threads List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Michael S. Tsirkin" , qemu-devel , Stefan Hajnoczi On 02/24/2012 02:43 PM, Paolo Bonzini wrote: > On 02/24/2012 08:22 PM, Anthony Liguori wrote: >> Virtio really wants each virtqueue to be processed in a separate >> thread. On a multicore system, there's considerable improvement doing >> this. I think that's where we ought to start. > > Well, that's where we ought to *get*. Stefan's work is awesome but with > the current feature set it would be hard to justify it upstream. > > To get it upstream we need to generalize it and make it work well with > the block layer. And vice versa make the block layer work well with > threads, which is what I care about here. > >> We really just need the block layer to be re-entrant, we don't >> actually need qcow2 or anything else that uses coroutines to use full >> threads. > > Once you can issue I/O from two threads at the same-time (such as > streaming in the iothread and guest I/O in the virtqueue thread), > everything already needs to be thread-safe. It is a pretty short step > from there to thread pools for everything. If you start with a thread safe API for submitting block requests, that could be implemented as bapi_aiocb *bapi_submit_readv(bapi_driver *d, struct iovec *iov, int iovcnt, off_t offset) { bapi_request *req = make_bapi_request(BAPI_READ, iov, iovcnt, offset); return bapi_queue_add_req(req); } Which would schedule the I/O thread to actually implement the operation. You could then start incrementally refactoring specific drivers to be re-entrant (like linux-aio). But anything that already needs to use a thread pool to do its I/O probably wouldn't benefit from threading virtio. More importantly, the above would give you good performance to start with, instead of refactoring a bunch of code hoping to eventually get to good performance. > >> Or at least, as far as I know, we don't have any performance data to >> suggest that we do. > > No, it's not about speed, though of course it only works if there is no > performance dip. It is just an enabling step. > > That said, my weekend officially begins now. :) Enjoy!! Regards, Anthony Liguori > > Paolo >