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

[malc]

On Thu, 25 Feb 2010, Avi Kivity wrote:

> 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?

Had(ve?) that on a private branch, there's no point in that complication.

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

-- 
mailto:address@hidden