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

[mdroth]

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
>