Re: [Qemu-devel] [PATCH for-2.3 0/5] aio: Support epoll by introducing qemu_poll abstraction

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]