From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2JSi-0001ee-BU for qemu-devel@nongnu.org; Tue, 28 Feb 2012 04:35:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2JSb-0004Gy-SI for qemu-devel@nongnu.org; Tue, 28 Feb 2012 04:35:11 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:52175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2JSb-0004Ep-Je for qemu-devel@nongnu.org; Tue, 28 Feb 2012 04:35:05 -0500 Received: by dadp14 with SMTP id p14so7491974dad.4 for ; Tue, 28 Feb 2012 01:35:03 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F4C9FBF.3000902@redhat.com> Date: Tue, 28 Feb 2012 10:34:55 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4F47DEB1.7080009@redhat.com> <4F47E37A.6000702@codemonkey.ws> <4F47F685.5010000@redhat.com> <4F47FA99.8050608@codemonkey.ws> In-Reply-To: <4F47FA99.8050608@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: qemu-devel , Stefan Hajnoczi , "Michael S. Tsirkin" Il 24/02/2012 22:01, Anthony Liguori ha scritto: >> 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). My proposal has exactly these two ingredients: a representations of block layer requests, and a fast path for AIO. But there are really two complementary parts to it. One is generalizing thread-pool support to non-raw formats, the other is doing I/O from multiple threads at the same time. The first is quite easy overall. The second is hard, because it's not just about reentrancy. You need various pieces of infrastructure that do not yet exist; for example you need freeze/unfreeze, because drain/drain_all is not enough if other threads can submit I/O concurrently. > But anything that already needs to use a thread pool to do its I/O > probably wouldn't benefit from threading virtio. Linux AIO _is_ a thread-pool in the end. It is surprising how close the latencies are between io_submit and cond_signal, for example. Paolo