Re: [Qemu-devel] [PATCH v4 00/10] main-loop: switch to g_poll(3) on POSIX hosts

[Stefan Hajnoczi]

On Wed, Feb 20, 2013 at 04:56:35PM +0200, Michael S. Tsirkin wrote:
> On Wed, Feb 20, 2013 at 11:28:23AM +0100, Stefan Hajnoczi wrote:
> > Amos Kong <address@hidden> reported that file descriptors numbered higher
> > than 1024 could crash QEMU.  This is due to the fixed size of the fd_set 
> > type
> > used for select(2) event polling.
> > 
> > This series converts the main-loop.c and aio-posix.c select(2) calls to
> > g_poll(3).  This eliminates the fd_set type and allows QEMU to scale to high
> > numbers of file descriptors.
> > 
> > The g_poll(3) interface is a portable version of the poll(2) system call.  
> > The
> > difference to select(2) is that fine-grained events (G_IO_IN, G_IO_OUT,
> > G_IO_HUP, G_IO_ERR, G_IO_PRI) can be monitored instead of just
> > read/write/exception.  Also, there is no limit to the file descriptor 
> > numbers
> > that may be used, allowing applications to scale to many file descriptors.  
> > See
> > the documentation for details:
> > 
> >   http://developer.gnome.org/glib/2.28/glib-The-Main-Event-Loop.html#g-poll
> > 
> > The QEMU main loop works as follows today:
> > 
> > 1. Call out to slirp, iohandlers, and glib sources to fill rfds/wfds/xfds 
> > with
> >    the file descriptors to select(2).
> > 2. Perform the select(2) call.
> > 3. Call out to slirp, iohandlers, and glib sources to handle events polled 
> > in
> >    rfds/wfds/xfds.
> > 
> > The plan of attack is as follows:
> > 
> > 1. Replace select(2) with g_poll(3).  Use glue that converts between
> >    rfds/wfds/xfds and GPollFD so that the unconverted QEMU components still
> >    work.
> > 
> > 2. Convert slirp, iohandlers, and glib source fill/poll functions to use
> >    GPollFD directly instead of rfds/wfds/xfds.
> > 
> > 3. Drop the glue since all components now natively use GPollFD.
> > 
> > 4. Convert aio-posix.c to g_poll(3) by reusing GPollFD.
> > 
> > I have tested that the series builds and is bisectable on Linux and Windows
> > hosts.  But I have not done extensive testing on other host platforms or 
> > with
> > long-term guests to check for performance regressions.
> 
> Wouldn't it make sense to switch to epoll instead?
> poll does not scale well to a huge number of descriptors.

A big factor for choosing g_poll(3) was portability.  If we maintain
different event polling mechanism for each host platform, we'll have
more support issues like we already do for Windows host.

Unless there is a pressing performance need, let's use the portable
solution.

Stefan