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(). Stefan
pgpAPxRvSykqV.pgp
Description: PGP signature
