[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/3] Refactor AIO interface to a
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
Fri, 02 May 2008 12:52:28 -0500
Thunderbird 126.96.36.199 (X11/20080227)
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.