qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, qemu-block@nongnu.org,
	Alberto Garcia <berto@igalia.com>,
	qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 11/11] block: Only poll block layer fds in bdrv_aio_poll
Date: Fri, 11 Sep 2015 19:01:22 +0800	[thread overview]
Message-ID: <20150911110122.GC9241@ad.nay.redhat.com> (raw)
In-Reply-To: <55F2B0EE.7030407@redhat.com>

On Fri, 09/11 12:46, Paolo Bonzini wrote:
> 
> 
> On 11/09/2015 12:40, Fam Zheng wrote:
> > On Fri, 09/11 11:54, Paolo Bonzini wrote:
> >>
> >>
> >> On 11/09/2015 11:44, Fam Zheng wrote:
> >>>>>> That would be a step back.  Using GSource is useful because it lets
> >>>>>> you integrate libraries such as GTK+.
> >>>>>
> >>>>> Can we move GTK to a separate GSource thread?
> >>>>
> >>>> I think that GTK should always run in the main thread, or at least the
> >>>> one running the default main loop / GMainContext.
> >>>
> >>> Yeah it's basically GMainContext staying in the main thread and
> >>> block/net/chardev I/O put in a new AioContext thread.
> >>
> >> Why?  The point of an event loop is that you can multiplex everything on
> >> the same thread.  Unless we have specific needs (e.g. scalability) one
> >> thread is the way to go and keep things simple.
> > 
> > The reason is scalability. :)
> 
> Scalability of what?  If virtio-net or virtio-serial needs to be more
> scalable, putting all of them into a non-main-loop thread will not make
> things more scalable, because you have a single thread anyway.  You'd
> need to go BQL-free and allow an arbitrary number.
> 
> > Moving things to AIO isn't deviation, it's more about enabling of dataplane and
> > epoll. That's why block was moved to AioContext, and I think we can do similar
> > for net and serial, the difference is that as a start, they don't need to be
> > fully BQL-free like virtio-blk and scsi. But by running in an aio_poll() loop,
> > they can better performance because of epoll.
> 
> Isn't that what your "iohandler.c with AioHandler" already does?  True,
> it would be epoll-within-poll, not pure poll.  But if you need epoll,
> you might as well go BQL-free.

epoll-within-poll? Do you mean change the main event loop from:

    qemu_poll_ns([..., ioeventfd1, ioeventfd2, ..., ioeventfd99], ...)

to

    qemu_poll_ns([epollfd], ...)

where epollfd watches all the fds, and let the handler of epollfd do
epoll_wait()?

Fam

  reply	other threads:[~2015-09-11 11:01 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-29  4:42 [Qemu-devel] [PATCH v2 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane Fam Zheng
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 01/11] aio: Introduce "type" in aio_set_fd_handler and aio_set_event_notifier Fam Zheng
2015-08-27 13:50   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 02/11] aio: Save type to AioHandler Fam Zheng
2015-08-27 13:50   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 03/11] block: Mark fd handlers as "protocol" Fam Zheng
2015-08-27 13:53   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-09-07  4:43     ` Fam Zheng
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 04/11] nbd: Mark fd handlers client type as "nbd server" Fam Zheng
2015-08-27 14:02   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 05/11] aio: Mark ctx->notifier's client type as "context" Fam Zheng
2015-08-27 17:12   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 06/11] dataplane: Mark host notifiers' client type as "dataplane" Fam Zheng
2015-08-27 17:14   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 07/11] aio-posix: introduce aio_{disable, enable}_clients Fam Zheng
2015-08-27 17:23   ` Stefan Hajnoczi
2015-09-07  5:26     ` Fam Zheng
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 08/11] aio-win32: Implement " Fam Zheng
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 09/11] block: Introduce bdrv_aio_poll Fam Zheng
2015-08-27 17:25   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-08-28 11:50   ` Stefan Hajnoczi
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 10/11] block: Replace nested aio_poll with bdrv_aio_poll Fam Zheng
2015-08-28 11:50   ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-07-29  4:42 ` [Qemu-devel] [PATCH v2 11/11] block: Only poll block layer fds in bdrv_aio_poll Fam Zheng
2015-07-29  7:36   ` Paolo Bonzini
2015-07-29  7:37   ` Paolo Bonzini
2015-07-29 10:57     ` Fam Zheng
2015-07-29 11:02       ` Paolo Bonzini
2015-07-29 11:53         ` Fam Zheng
2015-07-29 12:03           ` Paolo Bonzini
2015-07-30  1:35             ` Fam Zheng
2015-07-30 13:22               ` Paolo Bonzini
2015-09-09  3:22             ` Fam Zheng
2015-09-11  8:15               ` Paolo Bonzini
2015-09-11  9:14                 ` Fam Zheng
2015-09-11  9:36                   ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2015-09-11  9:43                     ` Daniel P. Berrange
2015-09-11  9:44                     ` Fam Zheng
2015-09-11  9:54                       ` Paolo Bonzini
2015-09-11 10:40                         ` Fam Zheng
2015-09-11 10:46                           ` Paolo Bonzini
2015-09-11 11:01                             ` Fam Zheng [this message]
2015-09-11 11:02                               ` Paolo Bonzini
2015-09-11 11:12                                 ` Fam Zheng
2015-09-11  9:45                     ` Paolo Bonzini
2015-07-29  7:38 ` [Qemu-devel] [PATCH v2 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane Paolo Bonzini
2015-08-28 11:53 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-09-07  6:28   ` Fam Zheng
2015-09-11 10:39 ` [Qemu-devel] " Kevin Wolf
2015-09-11 11:46   ` Fam Zheng
2015-09-11 12:22     ` Kevin Wolf
2015-09-14  7:27       ` Fam Zheng
2015-09-14  8:40         ` Kevin Wolf
2015-09-28  9:31       ` 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=20150911110122.GC9241@ad.nay.redhat.com \
    --to=famz@redhat.com \
    --cc=berto@igalia.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).