qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
Date: Tue, 15 Nov 2016 10:36:02 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Mon, Nov 14, 2016 at 06:15:46PM +0100, Paolo Bonzini wrote:
> 
> 
> On 14/11/2016 18:06, Stefan Hajnoczi wrote:
> >>> > > 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?
> 
> I mean ppoll.  If ppoll succeeds without ever going to sleep, you can
> achieve the same result with QEMU_AIO_POLL_MAX_NS=1, but cheaper.

It's not obvious to me that ioeventfd or Linux AIO will become ready
with QEMU_AIO_POLL_MAX_NS=1.

This benchmark is iodepth=1 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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]