All of lore.kernel.org
 help / color / mirror / Atom feed
From: mdroth <mdroth@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: aliguori@us.ibm.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:17:53 -0500	[thread overview]
Message-ID: <20130506181753.GB1685@vm> (raw)
In-Reply-To: <518761A6.4010209@redhat.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
> 

  parent reply	other threads:[~2013-05-06 18:20 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
2013-05-06 20:04       ` Paolo Bonzini
2013-05-06 18:17   ` mdroth [this message]
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=20130506181753.GB1685@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.