[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode |
Date: |
Mon, 14 Nov 2016 16:56:20 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Mon, Nov 14, 2016 at 08:52:21AM -0600, Karl Rister wrote:
> On 11/14/2016 07:53 AM, Fam Zheng wrote:
> > 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.
>
> Not yet, I was just trying to get something out as quick as I could
> (while juggling this with some other stuff...). Frankly I was a bit
> surprised that the low values made such an impact and then got
> distracted by the behaviors of 4, 8, and 64.
>
> >
> > Also, do you happen to have numbers for unpatched QEMU (just to confirm that
> > "unset" case doesn't cause regression) and baremetal for comparison?
>
> I didn't run this exact test on the same qemu.git master changeset
> unpatched. I did however previously try it against the v2.7.0 tag and
> got somewhere around 27.5K IOPs. My original intention was to apply the
> patches to v2.7.0 but it wouldn't build.
>
> We have done a lot of testing and tracing on the qemu-rhev package and
> 27K IOPs is about what we see there (with tracing disabled).
>
> Given the patch discussions I saw I was mainly trying to get a sniff
> test out and then do a more complete workup with whatever updates are made.
>
> I should probably note that there are a lot of pinning optimizations
> made here to assist in our tracing efforts which also result in improved
> performance. Ultimately, in a proper evaluation of these patches most
> of that will be removed so the behavior may change somewhat.
To clarify: QEMU_AIO_POLL_MAX_NS unset or 0 disables polling completely.
Therefore it's not necessary to run unpatched.
signature.asc
Description: PGP signature
- [Qemu-devel] [RFC 1/3] aio-posix: add aio_set_poll_handler(), (continued)
- [Qemu-devel] [RFC 3/3] linux-aio: poll ring for completions, Stefan Hajnoczi, 2016/11/09
- [Qemu-devel] [RFC 2/3] virtio: poll virtqueues for new buffers, Stefan Hajnoczi, 2016/11/09
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Karl Rister, 2016/11/11
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Stefan Hajnoczi, 2016/11/14
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Paolo Bonzini, 2016/11/14
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Stefan Hajnoczi, 2016/11/14
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Fam Zheng, 2016/11/14
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Paolo Bonzini, 2016/11/14
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Stefan Hajnoczi, 2016/11/15
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Fam Zheng, 2016/11/16
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Karl Rister, 2016/11/14
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Karl Rister, 2016/11/14
- Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode, Paolo Bonzini, 2016/11/14