[Qemu-devel] Re: high CPU load / async IO?

[Anthony Liguori <anthony@codemonkey.ws>]

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