[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: high CPU load / async IO?
From: |
Anthony Liguori |
Subject: |
[Qemu-devel] Re: high CPU load / async IO? |
Date: |
Mon, 24 Jul 2006 13:46:40 -0500 |
User-agent: |
Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux)) |
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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
- [Qemu-devel] high CPU load / async IO?, Sven Köhler, 2006/07/23
- [Qemu-devel] Re: high CPU load / async IO?,
Anthony Liguori <=
- [Qemu-devel] Re: high CPU load / async IO?, Sven Köhler, 2006/07/24
- [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