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:av1...@comtv.ru
