[Top][All Lists]
[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.
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] high CPU load / async IO?, Sven Köhler, 2006/07/23
- [Qemu-devel] Re: high CPU load / async IO?, Anthony Liguori, 2006/07/24
- [Qemu-devel] Re: high CPU load / async IO?,
Sven Köhler <=
- [Qemu-devel] Re: high CPU load / async IO?, Anthony Liguori, 2006/07/25
- [Qemu-devel] Re: high CPU load / async IO?, Sven Köhler, 2006/07/25
- Re: [Qemu-devel] Re: high CPU load / async IO?, Jens Axboe, 2006/07/25
- Re: [Qemu-devel] Re: high CPU load / async IO?, Fabrice Bellard, 2006/07/25
- Re: [Qemu-devel] Re: high CPU load / async IO?, Jens Axboe, 2006/07/26
- Re: [Qemu-devel] Re: high CPU load / async IO?, Paul Brook, 2006/07/26
- Re: [Qemu-devel] Re: high CPU load / async IO?, Jens Axboe, 2006/07/26
- Re: [Qemu-devel] Re: high CPU load / async IO?, Paul Brook, 2006/07/26
- Re: [Qemu-devel] Re: high CPU load / async IO?, Jens Axboe, 2006/07/26
- [Qemu-devel] Re: high CPU load / async IO?, Sven Köhler, 2006/07/26