From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ua2x7-00028M-Gs for qemu-devel@nongnu.org; Wed, 08 May 2013 07:54:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ua2x3-0007ta-8z for qemu-devel@nongnu.org; Wed, 08 May 2013 07:54:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ua2x3-0007tL-1H for qemu-devel@nongnu.org; Wed, 08 May 2013 07:54:29 -0400 Date: Wed, 8 May 2013 13:54:13 +0200 From: Stefan Hajnoczi Message-ID: <20130508115413.GC18210@stefanha-thinkpad.muc.redhat.com> References: <1367597032-28934-1-git-send-email-mdroth@linux.vnet.ibm.com> <518761A6.4010209@redhat.com> <20130506181753.GB1685@vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130506181753.GB1685@vm> 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: mdroth Cc: Paolo Bonzini , aliguori@us.ibm.com, qemu-devel@nongnu.org, qemulist@gmail.com On Mon, May 06, 2013 at 01:17:53PM -0500, mdroth wrote: > 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. Great. I see value in QOM, it allows event loop threads to be specified on the command-line and monitor. But it would be nice to drop QSource as well as the QContext inheritance hierarchy. BTW there should be a command analogous to query-cpus that lists the QContexts and their thread IDs. This way CPU affinity can be set similar to how we do it for vcpu threads today. Stefan