From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6HhM-0001dA-19 for qemu-devel@nongnu.org; Mon, 14 Nov 2016 08:53:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6HhI-0002vb-Rr for qemu-devel@nongnu.org; Mon, 14 Nov 2016 08:53:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38748) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6HhI-0002vG-Mz for qemu-devel@nongnu.org; Mon, 14 Nov 2016 08:53:20 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9170980083 for ; Mon, 14 Nov 2016 13:53:19 +0000 (UTC) Date: Mon, 14 Nov 2016 21:53:17 +0800 From: Fam Zheng Message-ID: <20161114135317.GB2373@lemon> References: <1478711602-12620-1-git-send-email-stefanha@redhat.com> <5826231D.7070208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5826231D.7070208@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: Stefan Hajnoczi , qemu-devel@nongnu.org, Paolo Bonzini , Andrew Theurer 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. Also, do you happen to have numbers for unpatched QEMU (just to confirm that "unset" case doesn't cause regression) and baremetal for comparison? Fam