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
