From: Stefan Hajnoczi <stefanha@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
pbonzini@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 4/4] aio-posix: Use epoll in aio_poll
Date: Tue, 7 Jul 2015 16:08:50 +0100 [thread overview]
Message-ID: <20150707150850.GG28673@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <1435670385-625-5-git-send-email-famz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]
On Tue, Jun 30, 2015 at 09:19:45PM +0800, Fam Zheng wrote:
> =====================================================================
> # of scsi-disks | master | epoll
> | rd wr randrw | rd wr randrw
> ---------------------------------------------------------------------
> 1 | 103 96 49 | 105 99 49
> 4 | 92 96 48 | 103 98 49
> 8 | 96 94 46 | 101 97 50
> 16 | 91 91 45 | 101 95 48
> 32 | 84 83 40 | 95 95 48
> 64 | 75 73 35 | 91 90 44
> 128 | 54 53 26 | 79 80 39
> 256 | 41 39 19 | 63 62 30
> =====================================================================
Nice results!
> @@ -44,6 +47,12 @@ static AioHandler *find_aio_handler(AioContext *ctx, int fd)
>
> void aio_context_setup(AioContext *ctx, Error **errp)
> {
> +#ifdef CONFIG_EPOLL
> + ctx->epollfd = epoll_create1(EPOLL_CLOEXEC);
> + if (ctx->epollfd < 0) {
> + error_setg(errp, "Failed to create epoll fd: %s", strerror(errno));
Slightly more concise:
error_setg_errno(errp, errno, "Failed to create epoll fd")
> -/* These thread-local variables are used only in a small part of aio_poll
> +#ifdef CONFIG_EPOLL
> +QEMU_BUILD_BUG_ON((int)G_IO_IN != EPOLLIN);
> +QEMU_BUILD_BUG_ON((int)G_IO_OUT != EPOLLOUT);
> +QEMU_BUILD_BUG_ON((int)G_IO_PRI != EPOLLPRI);
> +QEMU_BUILD_BUG_ON((int)G_IO_ERR != EPOLLERR);
> +QEMU_BUILD_BUG_ON((int)G_IO_HUP != EPOLLHUP);
I guess this assumption is okay but maybe the compiler optimizes:
event.events = (node->pfd.events & G_IO_IN ? EPOLLIN : 0) |
(node->pfd.events & G_IO_OUT ? EPOLLOUT : 0) |
(node->pfd.events & G_IO_PRI ? EPOLLPRI : 0) |
(node->pfd.events & G_IO_ERR ? EPOLLERR : 0) |
(node->pfd.events & G_IO_HUP ? EPOLLHUP : 0);
into:
events.events = node->pfd.events & (EPOLLIN | EPOLLOUT | EPOLLPRI |
EPOLLERR | EPOLLHUP);
which is just an AND instruction so it's effectively free and doesn't
assume that these constants have the same values.
> +
> +#define EPOLL_BATCH 128
> +static bool aio_poll_epoll(AioContext *ctx, bool blocking)
> +{
> + AioHandler *node;
> + bool was_dispatching;
> + int i, ret;
> + bool progress;
> + int64_t timeout;
> + struct epoll_event events[EPOLL_BATCH];
> +
> + aio_context_acquire(ctx);
> + was_dispatching = ctx->dispatching;
> + progress = false;
> +
> + /* aio_notify can avoid the expensive event_notifier_set if
> + * everything (file descriptors, bottom halves, timers) will
> + * be re-evaluated before the next blocking poll(). This is
> + * already true when aio_poll is called with blocking == false;
> + * if blocking == true, it is only true after poll() returns.
> + *
> + * If we're in a nested event loop, ctx->dispatching might be true.
> + * In that case we can restore it just before returning, but we
> + * have to clear it now.
> + */
> + aio_set_dispatching(ctx, !blocking);
> +
> + ctx->walking_handlers++;
> +
> + timeout = blocking ? aio_compute_timeout(ctx) : 0;
> +
> + if (timeout > 0) {
> + timeout = DIV_ROUND_UP(timeout, 1000000);
> + }
I think you already posted the timerfd code in an earlier series. Why
degrade to millisecond precision? It needs to be fixed up anyway if the
main loop uses aio_poll() in the future.
[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-07-07 15:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 13:19 [Qemu-devel] [PATCH RFC 0/4] aio: Use epoll_wait in aio_poll Fam Zheng
2015-06-30 13:19 ` [Qemu-devel] [PATCH RFC 1/4] aio: Introduce aio_set_fd_handler_pri Fam Zheng
2015-07-07 14:29 ` Stefan Hajnoczi
2015-07-08 1:07 ` Fam Zheng
2015-06-30 13:19 ` [Qemu-devel] [PATCH RFC 2/4] aio: Move aio_set_fd_handler to async.c Fam Zheng
2015-07-07 14:30 ` Stefan Hajnoczi
2015-06-30 13:19 ` [Qemu-devel] [PATCH RFC 3/4] aio: Introduce aio_context_setup Fam Zheng
2015-07-07 14:35 ` Stefan Hajnoczi
2015-07-08 1:15 ` Fam Zheng
2015-07-08 10:51 ` Stefan Hajnoczi
2015-06-30 13:19 ` [Qemu-devel] [PATCH RFC 4/4] aio-posix: Use epoll in aio_poll Fam Zheng
2015-07-07 15:08 ` Stefan Hajnoczi [this message]
2015-07-07 15:27 ` Paolo Bonzini
2015-07-08 1:01 ` Fam Zheng
2015-07-08 10:58 ` Stefan Hajnoczi
2015-07-10 0:46 ` Fam Zheng
2015-07-13 10:02 ` Stefan Hajnoczi
2015-07-07 14:54 ` [Qemu-devel] [PATCH RFC 0/4] aio: Use epoll_wait " Christian Borntraeger
2015-07-08 1:02 ` Fam Zheng
2015-07-08 7:59 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150707150850.GG28673@stefanha-thinkpad.redhat.com \
--to=stefanha@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).