On Tue, 11/25 13:52, Stefan Hajnoczi wrote: > On Tue, Nov 25, 2014 at 04:07:54PM +0800, Fam Zheng wrote: > > ppoll(2) doesn't scale as well as epoll: The elapsed time of the syscall is > > linear to the number of fd's we poll, which hurts performance a bit when the > > number of devices are many, or when a virtio device registers many > > virtqueues > > (virtio-serial, for instance). > > > > To show some data from my test on current master: > > > > - As a base point (10~20 fd's), it takes 22000 ns for each qemu_poll_ns. > > - Add 10 virtio-serial, which adds some 6 hundreds of fd's in the main > > loop. > > The time spent in qemu_poll_ns goes up to 75000 ns. > > > > This series introduces qemu_poll, which is implemented with g_poll and > > epoll, > > decided at configure time with CONFIG_EPOLL. > > > > After this change, the times to do the same thing with qemu_poll (more > > precisely, with a sequence of qemu_poll_set_fds(), qemu_poll(), > > qemu_poll_get_events() followed by syncing back to gpollfds), are reduced to > > 21000 ns and 25000 ns, respectively. > > > > We are still not O(1) because as a transition, the qemu_poll_set_fds before > > qemu_poll is not optimized out yet. > > You didn't mention the change from nanosecond to millisecond timeouts. > > QEMU did not use g_poll() for a long time because g_poll() only provides > milliseconds. It seems this patch series undoes the work that has been > done to keep nanosecond timeouts in QEMU. > > Do you think it is okay to forget about <1 ms timeout precision? > > If we go ahead with this, we'll need to rethink other timeouts in QEMU. > For example, is there a point in setting timer slack to 1 ns if we > cannot even specify ns wait times? > > Perhaps timerfd is needed before we can use epoll. Hopefully the > overall performance effect will be positive with epoll + timerfd, > compared to ppoll(). >
Good point! Thanks. I'll look into it. Fam
