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

["Sven Köhler" <skoehler@upb.de>]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

>> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]