From: Fam Zheng <famz@redhat.com>
To: Karl Rister <krister@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Andrew Theurer <atheurer@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
Date: Mon, 14 Nov 2016 21:53:17 +0800 [thread overview]
Message-ID: <20161114135317.GB2373@lemon> (raw)
In-Reply-To: <5826231D.7070208@redhat.com>
On Fri, 11/11 13:59, Karl Rister wrote:
>
> Stefan
>
> I ran some quick tests with your patches and got some pretty good gains,
> but also some seemingly odd behavior.
>
> These results are for a 5 minute test doing sequential 4KB requests from
> fio using O_DIRECT, libaio, and IO depth of 1. The requests are
> performed directly against the virtio-blk device (no filesystem) which
> is backed by a 400GB NVme card.
>
> QEMU_AIO_POLL_MAX_NS IOPs
> unset 31,383
> 1 46,860
> 2 46,440
> 4 35,246
> 8 34,973
> 16 46,794
> 32 46,729
> 64 35,520
> 128 45,902
For sequential read with ioq=1, each request takes >20000ns under 45,000 IOPs.
Isn't a poll time of 128ns a mismatching order of magnitude? Have you tried
larger values? Not criticizing, just trying to understand how it workd.
Also, do you happen to have numbers for unpatched QEMU (just to confirm that
"unset" case doesn't cause regression) and baremetal for comparison?
Fam
next prev parent reply other threads:[~2016-11-14 13:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 17:13 [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode Stefan Hajnoczi
2016-11-09 17:13 ` [Qemu-devel] [RFC 1/3] aio-posix: add aio_set_poll_handler() Stefan Hajnoczi
2016-11-09 17:30 ` Paolo Bonzini
2016-11-10 10:17 ` Stefan Hajnoczi
2016-11-10 13:20 ` Paolo Bonzini
2016-11-15 20:14 ` Fam Zheng
2016-11-09 17:13 ` [Qemu-devel] [RFC 2/3] virtio: poll virtqueues for new buffers Stefan Hajnoczi
2016-11-09 17:13 ` [Qemu-devel] [RFC 3/3] linux-aio: poll ring for completions Stefan Hajnoczi
2016-11-11 19:59 ` [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode Karl Rister
2016-11-14 13:53 ` Fam Zheng [this message]
2016-11-14 14:52 ` Karl Rister
2016-11-14 16:56 ` Stefan Hajnoczi
2016-11-14 15:26 ` Stefan Hajnoczi
2016-11-14 15:29 ` Paolo Bonzini
2016-11-14 17:06 ` Stefan Hajnoczi
2016-11-14 17:13 ` Fam Zheng
2016-11-14 17:15 ` Paolo Bonzini
2016-11-15 10:36 ` Stefan Hajnoczi
2016-11-16 8:27 ` Fam Zheng
2016-11-14 15:36 ` Karl Rister
2016-11-14 20:12 ` Karl Rister
2016-11-14 20:52 ` Paolo Bonzini
2016-11-15 10:32 ` Stefan Hajnoczi
2016-11-15 18:45 ` Karl Rister
2016-11-13 6:20 ` no-reply
2016-11-14 14:51 ` Christian Borntraeger
2016-11-14 16:53 ` Stefan Hajnoczi
2016-11-14 14:59 ` Christian Borntraeger
2016-11-14 16:52 ` Stefan Hajnoczi
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=20161114135317.GB2373@lemon \
--to=famz@redhat.com \
--cc=atheurer@redhat.com \
--cc=krister@redhat.com \
--cc=pbonzini@redhat.com \
--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).