On 02/09/2010 08:38 AM, Avi Kivity wrote:
On 02/09/2010 04:18 PM, Anthony Liguori wrote:
On 02/09/2010 02:52 AM, Jan Kiszka wrote:
Alexander Graf wrote:
On 09.02.2010, at 07:56, Avi Kivity wrote:
- rcuify/fine-grain qemu locks
And this should be done either way, but is probably not a
short-term goal.
Indeed. We won't get around this longterm as it is a scalability
bottleneck and a killer for RT guest load. We can't push everything
into
the kernel. Qemu needs a smart plan how to gradually convert its CPU
and
device model to fine-grained locking.
The VCPU loops should be easy to convert to lockless operation. It's
easier to do this upstream but that requires a functioning IO thread.
For the table based MMIO and PIO dispatch, RCU would be a good
locking choice since these structures are rarely updated. The tricky
bit is that the APIC has to be converted over to lockless before any
other device can be converted because just about every device wants
to inject an interrupt.
The problem is that all the internal APIs now have to be threaded.
Looking at hpet as a simple example, we have qemu_irq_pulse() and
qemu_mod_timer().
Yes. But just as you mention, we have to approach it on a
device-by-device basis and incrementally convert over devices.
We also have some lock inversion since hpet calls the timer but the
timers also call hpet.
Right. Making the dispatch loop in the IO thread thread safe won't be
so bad either :-)
qemu_irq_pulse() feeds the various interrupt controllers; not a
problem for kernel irqchip but nontrivial for qemu's ioapic and pic.
I'm not saying we should push hpet into the kernel to save userspace
coding effort; there should be an independent reason to do this. But
I don't think threading qemu is going to be anything near easy.
It's certainly not easy but I don't think it's impossibly hard.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
