[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-2.3 0/5] aio: Support epoll by introducing q
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [PATCH for-2.3 0/5] aio: Support epoll by introducing qemu_poll abstraction |
Date: |
Wed, 26 Nov 2014 13:27:53 +0800 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
- [Qemu-devel] [PATCH for-2.3 0/5] aio: Support epoll by introducing qemu_poll abstraction, Fam Zheng, 2014/11/25
- [Qemu-devel] [PATCH for-2.3 1/5] poll: Introduce QEMU Poll API, Fam Zheng, 2014/11/25
- [Qemu-devel] [PATCH for-2.3 3/5] poll: Add epoll implementation for qemu_poll, Fam Zheng, 2014/11/25
- [Qemu-devel] [PATCH for-2.3 2/5] posix-aio: Use QEMU poll interface, Fam Zheng, 2014/11/25
- [Qemu-devel] [PATCH for-2.3 4/5] main-loop: Replace qemu_poll_ns with qemu_poll, Fam Zheng, 2014/11/25
- [Qemu-devel] [PATCH for-2.3 5/5] tests: Add test case for qemu_poll, Fam Zheng, 2014/11/25
- Re: [Qemu-devel] [PATCH for-2.3 0/5] aio: Support epoll by introducing qemu_poll abstraction, Stefan Hajnoczi, 2014/11/25