All of lore.kernel.org
 help / color / mirror / Atom feed
From: mdroth <mdroth@linux.vnet.ibm.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, stefanha@redhat.com, qemulist@gmail.com
Subject: Re: [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops
Date: Mon, 6 May 2013 13:35:15 -0500	[thread overview]
Message-ID: <20130506183515.GC1685@vm> (raw)
In-Reply-To: <87obco2t3f.fsf@codemonkey.ws>

On Mon, May 06, 2013 at 07:25:24AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > 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.
> 
> Ack.
> 
> > However, it seems a bit overengineered.
> 
> Ack.
> 
> >  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
> > "just" introduce a glib-based QContext and be done with it.  Hopefully
> > that is the case...
> 
> Why even bother with QContext then?

The QContext/GlibQContext object in general, or the QContext base class?

In the case of the former, I think a wrapper around GLib that we can
instantiate from the command-line line and query properties like TIDs
from is necessary for robust control over event loops and CPU resources.
We get this essentially for free with QOM, so I think it makes sense to
use it.

In the case of the latter I'm not too sure. Without the QSource
abstraction there isn't much reason not to use the native GLib
interfaces on the underlying GSources/GMainContexts directly. In which
case GlibQContext would only need to be a container of sorts with some
minor additions like spawning an event thread for itself.

If we ever did need to switch it out in favor of a non-GLib
implementation, it should be a mostly mechanical conversion of
GSource->QSource and adding some wrappers around
g_main_context_prepare/check/etc.

Also along that line, if we're taking the approach of not adding
infrastructure/cruft until we actually have a plan to use it, it probably
makes sense to make QContext a concrete class implemented via GLib, and we
can move the GLib stuff to a sub-class later if we ever end up with another
QContext implementation.

Does this seem reasonable?

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > Paolo
> 

  reply	other threads:[~2013-05-06 18:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03 16:03 [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops Michael Roth
2013-05-03 16:03 ` [Qemu-devel] [PATCH 1/9] qom: add qom_init_completion Michael Roth
2013-05-06  7:45   ` Paolo Bonzini
2013-05-06 19:01     ` mdroth
2013-05-03 16:03 ` [Qemu-devel] [PATCH 2/9] qom: add object_property_add_unnamed_child Michael Roth
2013-05-06  7:44   ` Paolo Bonzini
2013-05-06 18:48     ` mdroth
2013-05-08 11:33       ` Stefan Hajnoczi
2013-05-03 16:03 ` [Qemu-devel] [PATCH 3/9] QSource: QEMU event source object Michael Roth
2013-05-03 16:03 ` [Qemu-devel] [PATCH 4/9] QContext: QEMU event loop context, abstract base class Michael Roth
2013-05-03 16:03 ` [Qemu-devel] [PATCH 5/9] GlibQContext: a QContext wrapper around GMainContexts Michael Roth
2013-05-03 16:03 ` [Qemu-devel] [PATCH 6/9] QContext: add unit tests Michael Roth
2013-05-03 16:03 ` [Qemu-devel] [PATCH 7/9] iohandler: associate with main event loop via a QSource Michael Roth
2013-05-06  7:53   ` Paolo Bonzini
2013-05-06 19:03     ` mdroth
2013-08-15  6:07     ` Wenchao Xia
2013-05-03 16:03 ` [Qemu-devel] [PATCH 8/9] main-loop: drive main event loop via QContext Michael Roth
2013-05-03 16:03 ` [Qemu-devel] [PATCH 9/9] dataplane: use a QContext event loop in place of custom thread Michael Roth
2013-05-06  7:54   ` Paolo Bonzini
2013-05-06 19:13     ` mdroth
2013-05-06  3:26 ` [Qemu-devel] [RFC 0/9] QContext: QOM class to support multiple event loops liu ping fan
2013-05-06 18:43   ` mdroth
2013-05-06  7:54 ` Paolo Bonzini
2013-05-06 12:25   ` Anthony Liguori
2013-05-06 18:35     ` mdroth [this message]
2013-05-06 20:04       ` Paolo Bonzini
2013-05-06 18:17   ` mdroth
2013-05-08 11:54     ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130506183515.GC1685@vm \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemulist@gmail.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.