From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOyiM-0001gw-Po for qemu-devel@nongnu.org; Tue, 24 May 2011 17:00:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOyiL-0004kU-V6 for qemu-devel@nongnu.org; Tue, 24 May 2011 17:00:30 -0400 Received: from mail2.shareable.org ([80.68.89.115]:48848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOyiL-0004kM-Qw for qemu-devel@nongnu.org; Tue, 24 May 2011 17:00:29 -0400 Date: Tue, 24 May 2011 22:00:25 +0100 From: Jamie Lokier Message-ID: <20110524210025.GT969@shareable.org> References: <1305233867-4367-1-git-send-email-jvrao@linux.vnet.ibm.com> <20110513085503.GA23158@stefanha-thinkpad.localdomain> <87sjsio0zi.fsf@linux.vnet.ibm.com> <4DCDCA6F.9000503@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCDCA6F.9000503@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [0/25] Async threading for VirtFS using glib threads & coroutines. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Venkateswararao Jujjuri Cc: Stefan Hajnoczi , aliguori@us.ibm.com, "Aneesh Kumar K.V" , stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org Venkateswararao Jujjuri wrote: > This model makes the code simple and also in one shot we can convert > all v9fs_do_syscalls into asynchronous threads. But as Aneesh raised > will there be any additional overhead for the additional jumps? We > can quickly test it out too. I'm not sure if this is exactly the right place (I haven't followed the whole discussion), but there is a useful trick for getting rid of one of the thread context switches: Swizzle *which* thread is your "main" coroutine thread. Instead of queuing up an item on the work queue, waking the worker thread pool, and having a worker thread pick up the coroutine, you: Declare the current thread to *be* a worker through from this point, and queue the calling context for a worker thread to pick up. When it picks it up, *that* thread declares itself to be the main thread coroutine thread. So the coroutine entry step is just queuing a context for another thread to pick up, and then diving into the blocking system call (optimising out the enqueue/dequeue and thread switch). In a sense, you make the "main" thread a long-lived work queue entry, and have a symmetric pool, except that the main thread tends to behave differently than the other work items. This only works if the main thread's state is able to follow the swizzling. I don't know if KVM VCPUs will do that, for example, or if there's other per-thread state that won't work. If the main thread can't be swizzled, you can still use this trick when doing the coroutine->syscall step starting form an existing worker thread. -- Jamie