From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFFvq-0002g8-8B for qemu-devel@nongnu.org; Fri, 30 Aug 2013 00:03:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFFvh-00053K-Am for qemu-devel@nongnu.org; Fri, 30 Aug 2013 00:03:34 -0400 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:60621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFFvN-0004cc-RZ for qemu-devel@nongnu.org; Fri, 30 Aug 2013 00:03:25 -0400 Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 30 Aug 2013 13:51:26 +1000 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 8BC153578053 for ; Fri, 30 Aug 2013 14:02:38 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7U3kTON64094408 for ; Fri, 30 Aug 2013 13:46:30 +1000 Received: from d23av03.au.ibm.com (localhost [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r7U42amQ008381 for ; Fri, 30 Aug 2013 14:02:37 +1000 Message-ID: <52201955.4080003@linux.vnet.ibm.com> Date: Fri, 30 Aug 2013 12:02:29 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1377614385-20466-1-git-send-email-stefanha@redhat.com> In-Reply-To: <1377614385-20466-1-git-send-email-stefanha@redhat.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC] aio: add aio_context_acquire() and aio_context_release() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Ping Fan Liu , qemu-devel@nongnu.org, Michael Roth , Anthony Liguori , Paolo Bonzini ÓÚ 2013-8-27 22:39, Stefan Hajnoczi дµÀ: > It can be useful to run an AioContext from a thread which normally does > not "own" the AioContext. For example, request draining can be > implemented by acquiring the AioContext and looping aio_poll() until all > requests have been completed. > > The following pattern should work: > > /* Event loop thread */ > while (running) { > aio_context_acquire(ctx); > aio_poll(ctx, true); > aio_context_release(ctx); > } > > /* Another thread */ > aio_context_acquire(ctx); > bdrv_read(bs, 0x1000, buf, 1); > aio_context_release(ctx); > > This patch implements aio_context_acquire() and aio_context_release(). > Note that existing aio_poll() callers do not need to worry about > acquiring and releasing - it is only needed when multiple threads will > call aio_poll() on the same AioContext. > > Signed-off-by: Stefan Hajnoczi > --- After a chat with Stefan on IRC, To enable block layer usage by multiple thread, there are two potential program models. Thanks for Stefan's analysis, I think it would be helpful to share the info as following, pls correct me if my understanding is not right: The models: 1) context per request model: aio_context_acquire(ctx); bds_acquire(bds); bdrv_aio_read(AioContext *ctx, BlockDriverStates *bds, ...); bds_release(bds); aio_context_release(ctx); 2) context per BDS model: BlockDriverState *bds = bdrv_new(AioContext *ctx); /* or another API bind AioContext */ aio_context_acquire(ctx); bdrv_aio_read(BlockDriverStates *bds, ...); aio_context_release(ctx); The difference: context per request model in 1): AioContext c0 AioContext c1 /|\ /|\ |----------------| | | ------------------- /|\ | | | BDS b0 BDS b1.. /|\ | ------------- /|\ /|\ | | request request from thread from thread t0 who t1 who acquired c0 acquired c1 context per BDS model in 2): AioContext c0 AioContext c1 /|\ | | | | | BDS b0 BDS b1.. /|\ | | request from thread t0 who acquired c0 (t1's request can't submitted at this time) If BDS is considered as front end used to submit task, AioContext is considered as a back end used to process task, whether to bind BDS with AioContext, determine whether the request for one BDS, can be submitted in front end, processed in the back end, in parallel. Generally speaking 1) will gain more parallel capability, it enable multiple thread usage at BDS level, but requires more code inside block layer, for sync and series/parallel request converting, so we are heading to 2), request will be submitted. Interesting thing is that, it can still enable multiple thread usage in AioContext level: AioContext c0 AioContext c1 /|\ /|\ | | | | BDS b0 BDS b1 /|\ /|\ | | | | request request from thread from thread t0 who t1 who acquired c0 acquired c1 So later dataplane thread will becomes another user who create a AioContext to do jobs in parallel. -- Best Regards Wenchao Xia