From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33885)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1c6Kor-0002F3-Hq
	for qemu-devel@nongnu.org; Mon, 14 Nov 2016 12:13:22 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1c6Kon-0000SQ-Ej
	for qemu-devel@nongnu.org; Mon, 14 Nov 2016 12:13:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:33666)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <famz@redhat.com>) id 1c6Kon-0000SM-9b
	for qemu-devel@nongnu.org; Mon, 14 Nov 2016 12:13:17 -0500
Date: Tue, 15 Nov 2016 01:13:14 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20161114171314.GA22598@lemon>
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: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161114170611.GE1352@stefanha-x1.localdomain>
Subject: Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Karl Rister <krister@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, qemu-devel@nongnu.org, Andrew Theurer <atheurer@redhat.com>

On Mon, 11/14 17:06, Stefan Hajnoczi wrote:
> On Mon, Nov 14, 2016 at 04:29:49PM +0100, Paolo Bonzini wrote:
> > On 14/11/2016 16:26, Stefan Hajnoczi wrote:
> > > On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
> > >> 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
> > > 
> > > The environment variable is in nanoseconds.  The range of values you
> > > tried are very small (all <1 usec).  It would be interesting to try
> > > larger values in the ballpark of the latencies you have traced.  For
> > > example 2000, 4000, 8000, 16000, and 32000 ns.
> > > 
> > > Very interesting that QEMU_AIO_POLL_MAX_NS=1 performs so well without
> > > much CPU overhead.
> > 
> > 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?
> 
> The benchmark uses virtio-blk dataplane and iodepth=1 so there shouldn't
> be much IOThread event loop activity besides the single I/O request.
> 
> The reason this puzzles me is that I wouldn't expect poll to succeed
> with QEMU_AIO_POLL_MAX_NS and iodepth=1.

I see the guest shouldn't send more requests, but isn't it possible for
the linux-aio poll to succeed?

Fam

> 
> Thanks,
> Stefan