Re: [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops

[Stefan Hajnoczi]

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