qemu-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]