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
signature.asc
Description: PGP signature