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
