From: Paolo Bonzini <pbonzini@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Cc: ming.lei@canonical.com, pl@kamp.de, stefanha@redhat.com,
mreitz@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v2 6/6] linux-aio: Queue requests instead of returning -EAGAIN
Date: Fri, 05 Dec 2014 19:15:38 +0100 [thread overview]
Message-ID: <5481F64A.3070203@redhat.com> (raw)
In-Reply-To: <1417795568-3201-7-git-send-email-kwolf@redhat.com>
On 05/12/2014 17:06, Kevin Wolf wrote:
> If the queue array for io_submit() is already full, but a new request
> arrives, we cannot add it to that queue anymore. We can, however, use a
> CoQueue, which is implemented as a list and can therefore queue as many
> requests as we want.
>
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
> block/linux-aio.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/block/linux-aio.c b/block/linux-aio.c
> index 373ec4b..8e6328b 100644
> --- a/block/linux-aio.c
> +++ b/block/linux-aio.c
> @@ -44,6 +44,7 @@ typedef struct {
> int plugged;
> unsigned int size;
> unsigned int idx;
> + CoQueue waiting;
> } LaioQueue;
>
> struct qemu_laio_state {
> @@ -160,6 +161,8 @@ static void ioq_init(LaioQueue *io_q)
> io_q->size = MAX_QUEUED_IO;
> io_q->idx = 0;
> io_q->plugged = 0;
> +
> + qemu_co_queue_init(&io_q->waiting);
> }
>
> static int ioq_submit(struct qemu_laio_state *s)
> @@ -201,15 +204,29 @@ static int ioq_submit(struct qemu_laio_state *s)
> s->io_q.idx * sizeof(s->io_q.iocbs[0]));
> }
>
> + /* Now there should be room for some more requests */
> + if (!qemu_co_queue_empty(&s->io_q.waiting)) {
> + if (qemu_in_coroutine()) {
> + qemu_co_queue_next(&s->io_q.waiting);
> + } else {
> + qemu_co_enter_next(&s->io_q.waiting);
We should get better performance by wrapping these with
plug/unplug. Trivial for the qemu_co_enter_next case, much less for
qemu_co_queue_next...
This exposes what I think is the main wrinkle in these patches: I'm not
sure linux-aio is a great match for the coroutine architecture. You
introduce some infrastructure duplication with block.c to track
coroutines, and I don't find the coroutine code to be an improvement
over Ming Lei's asynchronous one---in fact I actually find it more
complicated.
Paolo
> + }
> + }
> +
> return ret;
> }
>
> static int ioq_enqueue(struct qemu_laio_state *s, struct iocb *iocb)
> {
> unsigned int idx = s->io_q.idx;
> + bool was_waiting = false;
> + int ret = 0;
>
> - if (unlikely(idx == s->io_q.size)) {
> - return -EAGAIN;
> + while (unlikely(idx == s->io_q.size)) {
> + /* Wait for iocb slots to become free */
> + qemu_co_queue_wait(&s->io_q.waiting);
> + was_waiting = true;
> }
>
> s->io_q.iocbs[idx++] = iocb;
> @@ -217,10 +234,14 @@ static int ioq_enqueue(struct qemu_laio_state *s, struct iocb *iocb)
>
> /* submit immediately if queue is not plugged or full */
> if (!s->io_q.plugged || idx == s->io_q.size) {
> - return ioq_submit(s);
> - } else {
> - return 0;
> + ret = ioq_submit(s);
> + } else if (was_waiting) {
> + /* We were just woken up and there's stil room in the queue. Wake up
> + * someone else, too. */
> + qemu_co_queue_next(&s->io_q.waiting);
> }
> +
> + return ret;
> }
>
> void laio_io_plug(BlockDriverState *bs, void *aio_ctx)
>
next prev parent reply other threads:[~2014-12-05 18:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 16:06 [Qemu-devel] [RFC PATCH v2 0/6] linux-aio: Convert to coroutines Kevin Wolf
2014-12-05 16:06 ` [Qemu-devel] [RFC PATCH v2 1/6] qemu-img bench Kevin Wolf
2014-12-05 16:06 ` [Qemu-devel] [RFC PATCH v2 2/6] raw-posix: Convert Linux AIO submission to coroutines Kevin Wolf
2014-12-05 16:06 ` [Qemu-devel] [RFC PATCH v2 3/6] linux-aio: Don't reenter request coroutine recursively Kevin Wolf
2014-12-05 16:06 ` [Qemu-devel] [RFC PATCH v2 4/6] linux-aio: Support partial io_submits Kevin Wolf
2014-12-05 16:06 ` [Qemu-devel] [RFC PATCH v2 5/6] linux-aio: On -EAGAIN, wait for completions Kevin Wolf
2014-12-05 16:06 ` [Qemu-devel] [RFC PATCH v2 6/6] linux-aio: Queue requests instead of returning -EAGAIN Kevin Wolf
2014-12-05 18:15 ` Paolo Bonzini [this message]
2014-12-08 9:34 ` Kevin Wolf
2014-12-10 11:38 ` Paolo Bonzini
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=5481F64A.3070203@redhat.com \
--to=pbonzini@redhat.com \
--cc=kwolf@redhat.com \
--cc=ming.lei@canonical.com \
--cc=mreitz@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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).