Jamie Lokier wrote:
I'm under the impression that linux-aio is better in every way, as
I think Anthony Liguori posted a while back:
Threads are a poor substitute for a proper AIO interface.
linux-aio gives you everything you could possibly want in an
interface since it allows you to submit multiple vectored operations
in a single syscall, use an fd to signal request completion,
complete multiple requests in a single syscall, and inject barriers
via fdsync.
Well that Anthony Liguori guy is obviously smoking crack.
The problem with linux-aio is that it doesn't work unless you open a
file with O_DIRECT. There is no simple way to make it work with
buffered files either because of the silliness of the vfs interface.
I know buffered vs. unbuffered IO is a source of contention for some but
if you're doing largely homogeneous virtualization, and you happen to
have common storage (either via a common backing file or something more
sophisticated), buffered IO is going to make a big difference.
There are at least three thread pool implementations in the kernel to
allow asynchronous IO to buffered files. If the kernel is doing this
internally, userspace has no hope of being able to do it differently.
BTW, my current thinking for a thread pool implementation would actually
use linux-aio in each thread, but using it to emulate preadv/pwritev.
Regards,
Anthony Liguori
But knowing about request in flight, I/O ordering etc. seem equally
available via posix-aio on a distro where that calls linux-aio
(i.e. not the Glibc implementation).
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
