Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/3] Refactor AIO interface to allow other AIO implementations

[Anthony Liguori <anthony@codemonkey.ws>]

Jamie Lokier wrote:
> That makes sense - especially for formats like qcow and snapshots, the
> guest has very little knowledge of access timings.
>
> It's a bit like a database accessing a large file: the database tries
> to schedule and merge I/O requests internally before sending them to
> the kernel.  It doesn't know anything about the layout of disk blocks
> in the file, but it can guess that nearby accesses are more likely to
> involve lower seek times than far apart accesses.
>
> There is still one reason for guests to do a little I/O scheduling,
> and that's to merge adjacent requests into fewer ops passing through
> the guest/host interface.
>   

FWIW, in the process of optimizing the kernel driver for virtio-blk, 
I've found that using a no-op scheduler helps a fair bit.  As long as 
you're using a reasonably sized ring, the back-end can merge adjacent 
requests.  This also helps a fair bit too.

Regards,

Anthony Liguori

> -- Jamie
>
>
>