From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6b62-0001r2-KF for qemu-devel@nongnu.org; Tue, 15 Nov 2016 05:36:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6b5x-0004yv-OI for qemu-devel@nongnu.org; Tue, 15 Nov 2016 05:36:10 -0500 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:35861) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c6b5x-0004yb-Es for qemu-devel@nongnu.org; Tue, 15 Nov 2016 05:36:05 -0500 Received: by mail-wm0-x242.google.com with SMTP id m203so24254659wma.3 for ; Tue, 15 Nov 2016 02:36:05 -0800 (PST) Date: Tue, 15 Nov 2016 10:36:02 +0000 From: Stefan Hajnoczi Message-ID: <20161115103602.GC4836@stefanha-x1.localdomain> References: <1478711602-12620-1-git-send-email-stefanha@redhat.com> <5826231D.7070208@redhat.com> <20161114152642.GE26198@stefanha-x1.localdomain> <90b5f81f-eab0-72dc-63b8-143477cb5286@redhat.com> <20161114170611.GE1352@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: 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: Paolo Bonzini Cc: Karl Rister , Stefan Hajnoczi , qemu-devel@nongnu.org, Andrew Theurer , Fam Zheng --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2016 at 06:15:46PM +0100, Paolo Bonzini wrote: >=20 >=20 > On 14/11/2016 18:06, Stefan Hajnoczi wrote: > >>> > > Very interesting that QEMU_AIO_POLL_MAX_NS=3D1 performs so well w= ithout > >>> > > much CPU overhead. > >> >=20 > >> > That basically means "avoid a syscall if you already know there's > >> > something to do", so in retrospect it's not that surprising. Still > >> > interesting though, and it means that the feature is useful even if = you > >> > don't have CPU to waste. > > Can you spell out which syscall you mean? Reading the ioeventfd? >=20 > I mean ppoll. If ppoll succeeds without ever going to sleep, you can > achieve the same result with QEMU_AIO_POLL_MAX_NS=3D1, but cheaper. It's not obvious to me that ioeventfd or Linux AIO will become ready with QEMU_AIO_POLL_MAX_NS=3D1. This benchmark is iodepth=3D1 so there's just a single request. Fam suggested that maybe Linux AIO is ready immediately but AFAIK this NVMe device should still take a few microseconds to complete a request whereas our polling time is 1 nanosecond. Tracing would reveal what is going on here. Stefan --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYKuUSAAoJEJykq7OBq3PIWG0H/0FkS+TbpbsTodJlghgId6Hv mswchipS/EEcJSyIno3Ig2xwwyR348cv/Y6ROLXWsKB/CoLwXE9MaBzBRqFB6Tvz sSEXKlAZ+1KRbD8Sp0mJc1g5JBFe1beJlhYfJ8vjjCw4M/DQjJt4QBF1XTHoHwbC EqNXhZetkNbWp3CNZJDumjUx4kuxpbLB8qz8zk7HD7M8PgNn0X4obqooESiqtMGO NpyIz07qWUxe0AuxvRm/vJ/teHOmpcGSG2JXvcv2s3KLV5MOjruJFYvg5bGf4ttt 6yI//hUtT5dPK1WiOG6OpqiAMiBPm+XAagZojgw94n4Y1fVQWBmmVin3d0PDzpY= =1KtH -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ--