qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 0/7] aio: Support epoll by introducing qemu_p


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v3 0/7] aio: Support epoll by introducing qemu_poll abstraction
Date: Mon, 20 Apr 2015 11:36:34 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Apr 17, 2015 at 10:02:30AM +0800, Fam Zheng wrote:
> On Thu, 04/16 14:03, Stefan Hajnoczi wrote:
> > On Thu, Apr 16, 2015 at 12:57:29PM +0800, Fam Zheng wrote:
> > > v3: Rebase to master for 2.4.
> > >     Although epoll_pwait1 syscall is still being worked on [1], the QEMU 
> > > part
> > >     (if any) will base on this, so let's merge it first.
> > >     
> > >     That part is not included in this version because I'm still 
> > > evaluating by
> > >     comparing epoll_pwait1 with epoll+timerfd as with current master they 
> > > seem
> > >     to be really close.
> > > 
> > >     [1]: http://www.spinics.net/lists/linux-api/msg08216.html
> > > 
> > > v2: Emulate nanoseconds precison of timeout with ppoll and timerfd.
> > >     Their performance is on par with each other, but both much better than
> > >     qemu.git:
> > > 
> > >     syscall         high # of fd      low # of fd
> > >     -------------------------------------------------
> > >     qemu.git(ppoll) 44                96
> > >     ppoll+epoll     85                101
> > >     timerfd+epoll   87                109
> > > 
> > > (In high # of fd case, 3 activated but idle virtio-console devices are
> > > attached, which will add us hundereds of fds to poll)
> > 
> > Have you rerun benchmarks with this patch series?
> 
> Yes, here:
> 
>     syscall         high # of fd      low # of fd
>                     (Unit MB/s)       (Unit MB/s)
>     -------------------------------------------------
>     qemu.git(ppoll) 24                73
>     ppoll+epoll     49                77
>     timerfd+epoll   49                82

Nice.  Weird that the results are much lower than the v2 results, but
maybe the host changed?

> > 
> > I wonder how the ppoll-only performance changes.  It seems like there
> > are now additional copies of <fd, events, revents> information and
> > corresponding malloc/realloc/frees.

Please add a ppoll-only column hosts so we can be confident that the
non-epoll code works.  It will also show that non-Linux POSIX hosts
haven't regressed.

Thanks,
Stefan

Attachment: pgpd5iCD70qB3.pgp
Description: PGP signature


reply via email to

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