qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sven Köhler
Subject: [Qemu-devel] Re: high CPU load / async IO?
Date: Tue, 25 Jul 2006 00:51:23 +0200
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

>> 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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]