From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZQ1J-0000bU-1R for qemu-devel@nongnu.org; Mon, 06 May 2013 14:20:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZQ1C-0006Eu-Be for qemu-devel@nongnu.org; Mon, 06 May 2013 14:20:16 -0400 Received: from mail-vc0-f175.google.com ([209.85.220.175]:60013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZQ1C-0006Ed-89 for qemu-devel@nongnu.org; Mon, 06 May 2013 14:20:10 -0400 Received: by mail-vc0-f175.google.com with SMTP id lf10so3306446vcb.20 for ; Mon, 06 May 2013 11:20:09 -0700 (PDT) Sender: fluxion Date: Mon, 6 May 2013 13:17:53 -0500 From: mdroth Message-ID: <20130506181753.GB1685@vm> References: <1367597032-28934-1-git-send-email-mdroth@linux.vnet.ibm.com> <518761A6.4010209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <518761A6.4010209@redhat.com> Subject: Re: [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, stefanha@redhat.com, qemulist@gmail.com On Mon, May 06, 2013 at 09:54:14AM +0200, Paolo Bonzini wrote: > Il 03/05/2013 18:03, Michael Roth ha scritto: > > These patches apply on top of qemu.git master, and can also be obtained from: > > git://github.com/mdroth/qemu.git qcontext > > > > OVERVIEW > > > > This series introduces a set of QOM classes/interfaces for event > > registration/handling: QContext and QSource, which are based closely on > > their GMainContext/GSource GLib counterparts. > > > > QContexts can be created via the command-line via -object, and can also be > > intructed (via -object params/properties) to automatically start a > > thread/event-loop to handle QSources we attach to them. > > This is an awesome idea. > > However, it seems a bit overengineered. Why do we need QSource at all? > In my opinion, we should first change dataplane to use AioContext as a > GSource, and benchmark it thoroughly. If it is fast enough, we can I think it would be great to just stick with GSources. I didn't want to rely too heavily on GLib for the RFC since there seems to be some reservations about relying too heavily on GLib for our OneTrueEventLoop interface (mainly, lack of PI mutexes in the context of real-time device threads, or other performance considerations that might pop up and cause us to rethink our use of glib). However, knowing that we *could* do something like porting to QSources and using a different QContext implementation if the need ever became evident is enough for me, and I'm happy to drop QSources until we actually need them. The GSource->QSource conversions would be mostly mechanical. > GSource, and benchmark it thoroughly. If it is fast enough, we can > "just" introduce a glib-based QContext and be done with it. Hopefully > that is the case... Sounds good to me. I'll look into that more, and talk to some of our performance folks who were involved with the virtio-blk dataplane testing. > > Paolo >