Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

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.

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]