From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9vS8-0003rw-Lm for qemu-devel@nongnu.org; Tue, 30 Jun 2015 09:19:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9vS7-00035B-L4 for qemu-devel@nongnu.org; Tue, 30 Jun 2015 09:19:56 -0400 From: Fam Zheng Date: Tue, 30 Jun 2015 21:19:41 +0800 Message-Id: <1435670385-625-1-git-send-email-famz@redhat.com> Subject: [Qemu-devel] [PATCH RFC 0/4] aio: Use epoll_wait in aio_poll List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , pbonzini@redhat.com, qemu-block@nongnu.org, Stefan Hajnoczi epoll is more scalable than ppoll. It performs faster than ppoll when the number of polled fds is high. See patch 4 for an example of the senario and some benchmark data. Note: it is only effective on iothread (dataplane), while the main loop cannot benefit from this yet, because the iohandler and chardev GSource's don't easily fit into this epoll interface style (that's why main loop uses qemu_poll_ns directly instead of aio_poll()). There is hardly any timer activity in iothreads for now, as a result the timeout is always 0 or -1. Therefore, timerfd, or the said nanosecond epoll_pwait1 interface, which fixes the timeout granularity deficiency is not immediately necessary at this point, but still that will be simple to add. Please review! Fam Fam Zheng (4): aio: Introduce aio_set_fd_handler_pri aio: Move aio_set_fd_handler to async.c aio: Introduce aio_context_setup aio-posix: Use epoll in aio_poll aio-posix.c | 127 +++++++++++++++++++++++++++++++++++++++++++++++----- aio-win32.c | 7 +-- async.c | 24 ++++++++-- include/block/aio.h | 6 +++ 4 files changed, 144 insertions(+), 20 deletions(-) -- 2.4.3