From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6KYZ-0005tE-Ce for qemu-devel@nongnu.org; Mon, 14 Nov 2016 11:56:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6KYU-0003KR-EN for qemu-devel@nongnu.org; Mon, 14 Nov 2016 11:56:31 -0500 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:34904) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c6KYT-0003Ji-Ri for qemu-devel@nongnu.org; Mon, 14 Nov 2016 11:56:26 -0500 Received: by mail-wm0-x241.google.com with SMTP id a20so17029216wme.2 for ; Mon, 14 Nov 2016 08:56:25 -0800 (PST) Date: Mon, 14 Nov 2016 16:56:20 +0000 From: Stefan Hajnoczi Message-ID: <20161114165620.GD1352@stefanha-x1.localdomain> References: <1478711602-12620-1-git-send-email-stefanha@redhat.com> <5826231D.7070208@redhat.com> <20161114135317.GB2373@lemon> <5829CFA5.3060605@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Gf/FFewwPeBMqCJ" Content-Disposition: inline In-Reply-To: <5829CFA5.3060605@redhat.com> Subject: Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Karl Rister Cc: Fam Zheng , Andrew Theurer , Paolo Bonzini , qemu-devel@nongnu.org, Stefan Hajnoczi --3Gf/FFewwPeBMqCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 gain= s, > >> but also some seemingly odd behavior. > >> > >> These results are for a 5 minute test doing sequential 4KB requests fr= om > >> 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 > >=20 > > For sequential read with ioq=3D1, each request takes >20000ns under 45,= 000 IOPs. > > Isn't a poll time of 128ns a mismatching order of magnitude? Have you t= ried > > larger values? Not criticizing, just trying to understand how it workd. >=20 > 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. >=20 > >=20 > > Also, do you happen to have numbers for unpatched QEMU (just to confirm= that > > "unset" case doesn't cause regression) and baremetal for comparison? >=20 > 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. >=20 > 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). >=20 > 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 mad= e. >=20 > 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. --3Gf/FFewwPeBMqCJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYKey0AAoJEJykq7OBq3PIop4IALfQiFlGJAQj8fEEU+nrnKu+ b+qP2peZqz3fBW8FdTsq8lZ1j2fAUl4WqRVTvV+aDRZFtk1tQpniLuUe0p0e6I7J 9HOKGrEU1WpsGj1O6ka6yDAzeG0A5bVxVlQjgoATZoawZgyPSOHkjx+SXGTM+mYk KALQ2AWo2keePGzNPZ599+S9nqI5rE1KLpXCQxtxPLULw1YLsZngSklHMQZTO+hi YCi7iZl68C7RK6of11oOHx6QUZAMBMmFeKptYPSDdkf7/yljmLdVLv1pebNt7nFb TrTv/+V7cP5SkJ4g+BFheeW3LL4OhxxkS877o52ij1pa8NZwmNiiNI51kRLp8Ro= =J0SR -----END PGP SIGNATURE----- --3Gf/FFewwPeBMqCJ--