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 <ak...@redhat.com> 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
