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

[Jamie Lokier <jamie@shareable.org>]

Antonio Vargas wrote:
>      Btw, regarding QEMU: QEMU gets requests _after_ sorting by the
>      guest's
>      elevator, then submits them to the host's elevator.  If the guest and
>      host elevators are both configured 'anticipatory', do the
>      anticipatory
>      delays add up?
> 
> 
> Anticipatory is non-work-conserving. If the data is going to end passing thru
> host's deadline scheduler, probably it is better to the guest with deadline
> or maybe even no-op since it doesn't really know anything about the real
> disk locations of the data.

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.

-- Jamie