Re: [Qemu-devel] [Qemu-block] [PATCH v2 11/11] block: Only poll block layer fds in bdrv_aio_poll

[Fam Zheng <famz@redhat.com>]

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. :)

> 
> The tool we have for scalability is AioContext + dataplane threads, and
> because we _can_ integrate it into the main thread (AioContext is a
> GSource) we can write code once for the main thread and for external
> dataplane threads.

I don't think integrating with main thread or not is a problem, we can still
use the same code as before, because the event loop code change should be
transparent (see below).

> 
> Using AioContext instead of duplicating the code is great.  Moving SLIRP
> to Win32 would get rid of all the duplicated select() code between
> aio-win32.c and main-loop.c.  A lot of main-loop.c code can go away
> (probably not all because unlike glib we support nanosecond timeouts
> with TimerListGroup, but who knows).
> 
> However, there is no need to deviate the event loop from the well-known,
> standardized glib architecture.

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.

I'm thinking about something like this:

    Main thread (GTK):

        g_main_run()


    New io thread (one per process, includes block, net, serial):

        while (true) {
            qemu_mutex_lock_iothread();
            aio_poll(qemu_aio_context);
            qemu_mutex_unlock_iothread();
        }


    Dataplane thread (one per "-object iothread", includes dataplane enabled
    devices):

        while (true) {
            aio_poll(iothread->ctx);
        }

Fam