Gerd Hoffmann wrote: > > (I think the best > > route is a thread-pool based implementation). > > Not sure about that. linux-aio would have the advantage that the kernel > knows about all the requests in flight and probably can do a better job > on I/O ordering and scheduling then. But once we can have multiple > different implementations we can just try ;)
Won't posix-aio give the same info to the kernel when used with a sufficiently avante-garde Linux distro? 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. 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
