Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode

[Stefan Hajnoczi]

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