[Top][All Lists]

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

Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows gu

From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device
Date: Thu, 25 Feb 2010 19:33:15 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1

On 02/25/2010 07:15 PM, Anthony Liguori wrote:
I agree. Further, once we fine-grain device threading, the iothread essentially disappears and is replaced by device-specific threads. There's no "idle" anymore.

That's a nice idea, but how is io dispatch handled? Is everything synchronous or do we continue to program asynchronously?

Simple stuff can be kept asynchronous, complex stuff (like qcow2) ought to be made synchronous (it uses threads anyway, so we don't lose anything). Stuff like vnc can go either way.

It's very difficult to mix concepts.

We're complicated enough to have conflicting requirements and a large code base with its own inertia, so no choice really.

I personally don't anticipate per-device threading but rather anticipate re-entrant device models. I would expect all I/O to be dispatched within the I/O thread and the VCPU threads to be able to execute device models simultaneously with the I/O thread.

That means long-running operations on the iothread can lock out other completions.

Candidates for own threads are:
- live migration
- block format drivers (except linux-aio, perhaps have a thread for the aio completion handler)
- vnc
- sdl
- sound?
- hotplug, esp. memory

Each such thread could run the same loop as the iothread. Any pollable fd or timer would be associated with a thread, so things continue as normal more or less. Unassociated objects continue with the main iothread.

Do not meddle in the internals of kernels, for they are subtle and quick to 

reply via email to

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