On Mon, 24 Jul 2006 00:47:21 +0200, Sven Köhler wrote: > 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. 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). 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. Regards, Anthony Liguori > Why i'm curious? Well, i'm curious about the improvement it causes. You > people once told me, that the boost will not be that significant. On the > other hand, i see my host CPU usage going towards 100% just because the > guest is doing some IO or ... or is it because of somethine else > perhaps? > > To be concrete: have you guys ever run windows-update inside qemu? Well, > my win2k guest consumes all CPU on the host for some reason. What might > be the reason? > (qemu is started with -kernel-kqemu -m 256 -soundhw es1370) > > Also windows-update's green "progress bar" inside the guest is stopping > for let's say 3 or 5 seconds and not moving continuous. > > Is anybody experiencing the same or knows the reason? > > > Thanks, > Sven > _______________________________________________ Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
