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.
