On 02/09/2010 12:56 AM, Avi Kivity wrote:
On 02/09/2010 03:28 AM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
hpet overhead on large smp guests
I measured hpet consuming about a half a core's worth of cpu on an
idle Windows 2008 R2 64-way guest. This is mostly due to futex
contention, likely from the qemu mutex.
Options:
- ignore, this is about 1% of the entire system (but overhead might
increase greatly if a workload triggers more hpet accesses)
- push hpet into kernel, with virtio-net, virtio-blk, and kernel-hpet,
there's little reason to exit into qemu
Security, shamurity, let's just stick all of qemu in the kernel :-)
- rcuify/fine-grain qemu locks
Should be pretty straight forward. It would start with removing the
locking within kvm*.c such that qemu_mutex isn't acquired until we
dispatch I/O operations. Then we can add lockless paths for dispatch as
we convert device models over.
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
