>> 3) async block I/O (not merged yet) >> It's not in HEAD yet, isn't it? > > The pthread-based async patch is a band-aid. No doubt it helps your > particular case, but it's not the right approach long term. > > IDE only supports one outstanding request, so having a thread that runs > the synchronous block routines appears reasonable. However, SATA and SCSI > both support multiple outstanding requests. The extension to the existing > patch would be simple--increase the number of threads.
??? Wasn't there another variant using the async-I/O support of the Host OS and thereby supporting a larger number of outstanding requests? > A number of Xen hackers (primarily Andy Warfield and Dan Smith) have been > doing a lot of work analyzing userspace block device performance. As > QEMU's CPU virtualization gets faster (ala kqemu or VT/SVM), it will start > facing the same bottlenecks that we do today in Xen. > > To achieve near-native performance, you basically have to be able to > saturate the host's IO scheduler queue. Using O_DIRECT, you can do > zero-copy meaning that your ability to queue requests is the only limiting > factor. > > What's been discovered is that a thread based approach requires a ton of > threads to achieve saturation. Just imagine the contention of having a > very large number of threads trying to get at a single BDRVState. > > The real solution is to modify the block API to be asynchronous and then > provide support for interacting with the host IO scheduler queue via > something like linux-aio (or the win32 equiv). The approch that i mentioned above (using the host's async I/O) is what you mean with using linux-aio, right? > So the current thread-based async dma patch is really just the wrong long > term solution. A more long term solution is likely in the works. It > requires quite a bit of code modification though. I see. So in other words: don't ask for simple async I/O now. The more complex and flexible sollution will follow soon.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
