On 03/29/2010 06:00 PM, Anthony Liguori wrote:
In qemu, we tend to prefer state-machine based code.
There are a few different models that we have discussed at different
points:
1) state machines with a thread pool to make blocking functions
asynchronous (what we have today)
2) co-operative threading
3) pre-emptive threading
All three models are independent of making device models re-entrant.
In order to allow VCPU threads to run in qemu simultaneously, we need
each device to carry a lock and for that lock to be acquired upon any
of the public functions for the device model.
For individual device models or host services, I think (3) is probably
the worst model overall. I personally think that (1) is better in the
long run but ultimately would need an existence proof to compare
against (2). (2) looks appealing until you actually try to have the
device handle multiple requests at a time.
Sooner or later nature and the ever more complicated code will force us
towards (3). As an example, we've observed live migration to throttle
vcpus when sending a large guest's zeroed memory over; the bandwidth
control doesn't kick in since zero pages are compressed, so the iothread
spends large amounts of time reading memory.
We could fix this by yielding every so often (and a patch will be posted
soon), but it remains an issue. We have too much work in the I/O thread
and that defers I/O completion and timers.
For virtio-9p, I don't think (1) is much of a burden to be honest. In
particular, when the 9p2000.L dialect is used, there should be a 1-1
correlation between protocol operations and system calls which means
that for the most part, there's really no advantage to threading from
a complexity point of view.
But if those system calls are blocking, you need a thread?
On a philosophical note, threads may be easier to model complex hardware
that includes a processor, for example our scsi card (and how about
using tcg as a jit to boost it :)
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
