Andrea Arcangeli wrote:
My current feeling is that this user thread aio thing will never
satisfy enterprise usage and kernel aio is mandatory in my view.
Well, linux kernel aio has its share of problems too:
* Anthony mentioned it may block on certain circumstances (forgot
which ones), and you can't figure beforehand to turn off aio then.
* It can't handle block allocation. Kernel handles that by doing
such writes synchronously via VFS layer (instead of the separate
aio code paths). Leads to horrible performance and bug reports
such as "installs on sparse files are very slow".
* support for vectored aio isn't that old. IIRC it was added
somewhen around 2.6.20 (newer that current suse/redhat enterprise
versions). Which IMHO means you can't expect it being present
unconditionally.
And we should concentrate on kernel aio and get rid
of threads when host OS is linux.
Threads will be there anyway for kvm smp.
Has anybody a patch implementing kernel aio that I can plug into the
dma zerocopy api? I'm not so sure clone aio is worth maintaining
inside qemu instead of evolving glibc
Well, wait for glibc isn't going to fly. glibc waits for posix, and
posix waits for a reference implementation (which will not be glibc).
and kernel with preadv/pwritev
With that in place you don't need kernel aio any more, then you can
really do it in userspace with threads. But that probably would be
linux-only ^W^W^W