Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device

[Avi Kivity <avi@redhat.com>]

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