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